Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 17:29:09 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89 14:13:58 PST Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 16:16:10 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:57:36 EST Received: by verdi.think.com; Wed, 4 Jan 89 16:55:50 EST Date: Wed, 4 Jan 89 16:55:50 EST From: Guy Steele Message-Id: <8901042155.AA10486@verdi.think.com> To: eb@lucid.com Cc: gls@Think.COM, Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: Eric Benson's message of Wed, 4 Jan 89 13:34:57 pst <8901042134.AA00501@blacksox> Subject: PROG1 as a function Date: Wed, 4 Jan 89 13:34:57 pst From: Eric Benson Date: Wed, 4 Jan 89 16:23:48 EST From: Guy Steele Sigh. Unfortunately, I must beg to differ. I read the passage on page 194 as requiring only that the fully evaluated arguments be processed left-to-right for contagion purposes. This is not the same as requiring that argument forms in a call be evaluated left-to-right. -- Guy Maybe you're looking at the wrong passage. This looks pretty unambiguous to me. It's also the only place in CLtL that says argument evaluation is always left-to-right: "For functions that are mathematically associative (and possibly commutative), a Common Lisp implementation may process the arguments in any manner consistent with associative (and possibly commutative) rearrangement. This does not affect the order in which the argument forms are evaluated, of course; that order is always left-to-right, as in all Common Lisp function calls. What is left loose is the order in which the argument values are processed." Ooops. Sorry. I was wedged and looking in the wrong place. "Never mind." --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 17:09:43 EST Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 13:54:26 PST Received: from mist.encore.COM by multimax.encore.com (5.59/25-eef) id AA07451; Wed, 4 Jan 89 16:53:07 EST Received: from localhost by mist. (4.0/SMI-4.0) id AA14516; Wed, 4 Jan 89 16:53:06 EST Message-Id: <8901042153.AA14516@mist.> To: Barry Margolin Cc: Eric Benson , common-lisp@sail.stanford.edu Subject: Re: PROG1 as a function; meta-rules of CLtL In-Reply-To: Your message of Wed, 04 Jan 89 15:47:00 -0500. <19890104204747.1.BARMAR@OCCAM.THINK.COM> Date: Wed, 04 Jan 89 16:53:00 EST From: Dan L. Pierson Date: Wed, 4 Jan 89 15:47 EST From: Barry Margolin Date: Wed, 4 Jan 89 09:19:35 pst From: Eric Benson Is it OK to define Common Lisp functions with extra optional or keyword parameters, with system dependent meanings? E.g. Lucid's COMPILE-FILE has several keyword arguments not mentioned in CLtL. Is it OK to return extra values from Common Lisp functions? Is it OK to define the behavior of functions on datatypes not explicitly permitted in CLtL? For example, suppose I defined + on vectors to do componentwise addition on the elements? Arguments to + "must" be numbers, meaning that it "is an error" to supply anything other than numbers, meaning that anything can happen when you supply arguments other than numbers. Those of us in X3J13 have been thinking about this general problem for several years, but there still isn't a clear concensus. I believe that it was the original intent of the CL designers that implementations be permitted to do many of these things. Anything that "is an error" is a potential place for extension. Symbolics has done all of the above. Adding optional parameters or returning extra values is usually safe. I have to disagree. Adding new keyword parameters is fairly safe, since a new version of the Common Lisp standard would have to use that exact keyword name in an incompatible way to cause a problem. However adding a new optional parameter guarantees that any new standard which adds a new optional or required parameter to the form will cause trouble (unless, of course, the change in the standard was to adopt the implementation extension in question). Since the Common Lisp standard is (and will be, I hope) created by consensus as much as possible, the most likely effect of such an implementation extension is to restrict the options of any new standard. I would personally encourage implementations to make any additions to Common Lisp forms via new keyword arguments rather than optional arguments; I hope that the final X3J13 standard will specify this. Returning extra values is a harder problem. It causes the same problems as new optional arguments, but there is more likely to be no reasonable alternative.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 16:52:23 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 13:37:19 PST Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04590g; Wed, 4 Jan 89 13:32:41 PST Received: by blacksox id AA00501g; Wed, 4 Jan 89 13:34:57 pst Date: Wed, 4 Jan 89 13:34:57 pst From: Eric Benson Message-Id: <8901042134.AA00501@blacksox> To: gls@Think.COM Cc: Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: Guy Steele's message of Wed, 4 Jan 89 16:23:48 EST <8901042123.AA10344@verdi.think.com> Subject: PROG1 as a function Date: Wed, 4 Jan 89 16:23:48 EST From: Guy Steele Sigh. Unfortunately, I must beg to differ. I read the passage on page 194 as requiring only that the fully evaluated arguments be processed left-to-right for contagion purposes. This is not the same as requiring that argument forms in a call be evaluated left-to-right. -- Guy Maybe you're looking at the wrong passage. This looks pretty unambiguous to me. It's also the only place in CLtL that says argument evaluation is always left-to-right: "For functions that are mathematically associative (and possibly commutative), a Common Lisp implementation may process the arguments in any manner consistent with associative (and possibly commutative) rearrangement. This does not affect the order in which the argument forms are evaluated, of course; that order is always left-to-right, as in all Common Lisp function calls. What is left loose is the order in which the argument values are processed."  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 16:46:27 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89 13:29:47 PST Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 15:46:00 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:27:29 EST Received: by verdi.think.com; Wed, 4 Jan 89 16:25:43 EST Date: Wed, 4 Jan 89 16:25:43 EST From: Guy Steele Message-Id: <8901042125.AA10347@verdi.think.com> To: Greenwald@stony-brook.scrc.symbolics.com Cc: Moon@stony-brook.scrc.symbolics.com, barmar@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: Michael Greenwald's message of Wed, 4 Jan 89 14:17 EST <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM> Subject: PROG1 as a function Date: Wed, 4 Jan 89 14:17 EST From: Michael Greenwald Date: Wed, 4 Jan 89 13:49 EST From: David A. Moon Date: Tue, 3 Jan 89 20:10 EST From: Barry Margolin One of our users noticed today that Symbolics defines PROG1 as a function, rather than as a macro as CLtL specifies. The definition is essentially (defun prog1 (first-form &rest rest-forms) (declare (ignore rest-forms)) first-form) This works because CL requires left-to-right evaluation of function arguments CLtL is vague about the order of evaluation of function arguments. In chapters 5 and 7 it neither says that the order is left-to-right nor that the order is undefined, and I suspect that the person who made PROG1 a macro thought the order was undefined; I can't see any other reason that it would need to be a macro. The place in CLtL that says that all function arguments are evaluated left-to-right is page 194, buried in the middle of a discussion on numeric contagion. Actually, CLtL pg 61 says that the arguments and parameters are processed in order, from left to right. I don't know if "processed" implies "evaluated", but I always assumed (perhaps incorrectly) it did. I interpret this as referring to how the (fully evaluated) arguments are processed during lambda-binding, not to the order in which argument forms in a function call are evaluated. After all, the arguments referred to on page 61 might have come from a list given to APPLY, rather then from EVAL on a function call. --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 16:45:03 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89 13:28:19 PST Received: from fafnir.think.com by Think.COM; Wed, 4 Jan 89 15:44:14 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Wed, 4 Jan 89 16:25:37 EST Received: by verdi.think.com; Wed, 4 Jan 89 16:23:48 EST Date: Wed, 4 Jan 89 16:23:48 EST From: Guy Steele Message-Id: <8901042123.AA10344@verdi.think.com> To: Moon@stony-brook.scrc.symbolics.com Cc: barmar@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: David A. Moon's message of Wed, 4 Jan 89 13:49 EST <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Subject: PROG1 as a function Date: Wed, 4 Jan 89 13:49 EST From: David A. Moon Date: Tue, 3 Jan 89 20:10 EST From: Barry Margolin One of our users noticed today that Symbolics defines PROG1 as a function, rather than as a macro as CLtL specifies. The definition is essentially (defun prog1 (first-form &rest rest-forms) (declare (ignore rest-forms)) first-form) This works because CL requires left-to-right evaluation of function arguments CLtL is vague about the order of evaluation of function arguments. In chapters 5 and 7 it neither says that the order is left-to-right nor that the order is undefined, and I suspect that the person who made PROG1 a macro thought the order was undefined; I can't see any other reason that it would need to be a macro. The place in CLtL that says that all function arguments are evaluated left-to-right is page 194, buried in the middle of a discussion on numeric contagion. Sigh. Unfortunately, I must beg to differ. I read the passage on page 194 as requiring only that the fully evaluated arguments be processed left-to-right for contagion purposes. This is not the same as requiring that argument forms in a call be evaluated left-to-right. -- Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 16:08:02 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 4 Jan 89 12:51:58 PST Return-Path: Received: from sauron.think.com by Think.COM; Wed, 4 Jan 89 15:06:58 EST Received: from OCCAM.THINK.COM by sauron.think.com; Wed, 4 Jan 89 15:48:06 EST Date: Wed, 4 Jan 89 15:47 EST From: Barry Margolin Subject: PROG1 as a function; meta-rules of CLtL To: Eric Benson Cc: common-lisp@sail.stanford.edu In-Reply-To: <8901041719.AA00451@blacksox> Message-Id: <19890104204747.1.BARMAR@OCCAM.THINK.COM> Date: Wed, 4 Jan 89 09:19:35 pst From: Eric Benson Date: Tue, 3 Jan 89 20:10 EST From: Barry Margolin One of our users noticed today that Symbolics defines PROG1 as a function, rather than as a macro as CLtL specifies. The definition is essentially (defun prog1 (first-form &rest rest-forms) (declare (ignore rest-forms)) first-form) This works because CL requires left-to-right evaluation of function arguments; it just does a bit more consing than a macro implementation would need to do. Actually, it doesn't do any more consing than the macro definition, because &REST arguments are stack-allocated on Symbolics machines (in generally-agreed-on violation of CLtL). Even in Lucid's implementation this definition would not cons, because the ignored rest argument is never created in the first place. True. I didn't realize that EVAL consed the arguments on the stack (I thought only compiled code did it). Is it OK to define Common Lisp functions with extra optional or keyword parameters, with system dependent meanings? E.g. Lucid's COMPILE-FILE has several keyword arguments not mentioned in CLtL. Is it OK to return extra values from Common Lisp functions? Is it OK to define the behavior of functions on datatypes not explicitly permitted in CLtL? For example, suppose I defined + on vectors to do componentwise addition on the elements? Arguments to + "must" be numbers, meaning that it "is an error" to supply anything other than numbers, meaning that anything can happen when you supply arguments other than numbers. Those of us in X3J13 have been thinking about this general problem for several years, but there still isn't a clear concensus. I believe that it was the original intent of the CL designers that implementations be permitted to do many of these things. Anything that "is an error" is a potential place for extension. Symbolics has done all of the above. Adding optional parameters or returning extra values is usually safe. Programs can get in trouble, though, if they use multiple-value-list or multiple-value-call with functions that have been extended in such ways. For instance, (multiple-value-call #'cons (floor x y)) looks portable, but it will try to pass the wrong number of arguments to CONS if FLOOR returns an extra value. Suppose an implementation printed >>Attention: Taking CAR of (1 2 3)! every time CAR was called. I don't suppose many people would use it, but would it be a legal Common Lisp implementation? This is something I remember Kent Pitman bringing up a long time ago, under the general topic of automatic output. The above is obviously an extreme case, but there are realistic analogues, such as GC notifications, autoload heralds, and progress messages from COMPILE-FILE or LOAD. Since we weren't sure how to tackle these, we've generally dismissed them as "environment" features, which CL generally doesn't address. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 14:43:19 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89 11:31:24 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515226; Wed 4-Jan-89 14:29:52 EST Date: Wed, 4 Jan 89 14:29 EST From: David A. Moon Subject: PROG1 as a function To: Michael Greenwald cc: barmar@Think.COM, common-lisp@sail.stanford.edu In-Reply-To: <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM> Message-ID: <19890104192915.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Wed, 4 Jan 89 14:17 EST From: Michael Greenwald Date: Wed, 4 Jan 89 13:49 EST From: David A. Moon CLtL is vague about the order of evaluation of function arguments. Actually, CLtL pg 61 says that the arguments and parameters are processed in order, from left to right. I don't know if "processed" implies "evaluated", but I always assumed (perhaps incorrectly) it did. "Arguments" are the output from evaluation, not the input to evaluation. Think about the case where the function was called by APPLY.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 14:25:03 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89 11:11:19 PST Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 515201; 4 Jan 89 14:09:38 EST Date: Wed, 4 Jan 89 14:17 EST From: Michael Greenwald Subject: PROG1 as a function To: Moon@STONY-BROOK.SCRC.Symbolics.COM, barmar@Think.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <19890104191710.7.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM> Date: Wed, 4 Jan 89 13:49 EST From: David A. Moon Date: Tue, 3 Jan 89 20:10 EST From: Barry Margolin One of our users noticed today that Symbolics defines PROG1 as a function, rather than as a macro as CLtL specifies. The definition is essentially (defun prog1 (first-form &rest rest-forms) (declare (ignore rest-forms)) first-form) This works because CL requires left-to-right evaluation of function arguments CLtL is vague about the order of evaluation of function arguments. In chapters 5 and 7 it neither says that the order is left-to-right nor that the order is undefined, and I suspect that the person who made PROG1 a macro thought the order was undefined; I can't see any other reason that it would need to be a macro. The place in CLtL that says that all function arguments are evaluated left-to-right is page 194, buried in the middle of a discussion on numeric contagion. Actually, CLtL pg 61 says that the arguments and parameters are processed in order, from left to right. I don't know if "processed" implies "evaluated", but I always assumed (perhaps incorrectly) it did.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 14:07:19 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 4 Jan 89 10:54:47 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 515182; Wed 4-Jan-89 13:50:23 EST Date: Wed, 4 Jan 89 13:49 EST From: David A. Moon Subject: PROG1 as a function To: Barry Margolin cc: common-lisp@sail.stanford.edu In-Reply-To: <19890104011056.6.BARMAR@OCCAM.THINK.COM> Message-ID: <19890104184948.9.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Tue, 3 Jan 89 20:10 EST From: Barry Margolin One of our users noticed today that Symbolics defines PROG1 as a function, rather than as a macro as CLtL specifies. The definition is essentially (defun prog1 (first-form &rest rest-forms) (declare (ignore rest-forms)) first-form) This works because CL requires left-to-right evaluation of function arguments CLtL is vague about the order of evaluation of function arguments. In chapters 5 and 7 it neither says that the order is left-to-right nor that the order is undefined, and I suspect that the person who made PROG1 a macro thought the order was undefined; I can't see any other reason that it would need to be a macro. The place in CLtL that says that all function arguments are evaluated left-to-right is page 194, buried in the middle of a discussion on numeric contagion.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 12:35:56 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 09:21:03 PST Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA04233g; Wed, 4 Jan 89 09:17:15 PST Received: by blacksox id AA00451g; Wed, 4 Jan 89 09:19:35 pst Date: Wed, 4 Jan 89 09:19:35 pst From: Eric Benson Message-Id: <8901041719.AA00451@blacksox> To: barmar@Think.COM Cc: common-lisp@sail.stanford.edu In-Reply-To: Barry Margolin's message of Tue, 3 Jan 89 20:10 EST <19890104011056.6.BARMAR@OCCAM.THINK.COM> Subject: PROG1 as a function; meta-rules of CLtL Date: Tue, 3 Jan 89 20:10 EST From: Barry Margolin One of our users noticed today that Symbolics defines PROG1 as a function, rather than as a macro as CLtL specifies. The definition is essentially (defun prog1 (first-form &rest rest-forms) (declare (ignore rest-forms)) first-form) This works because CL requires left-to-right evaluation of function arguments; it just does a bit more consing than a macro implementation would need to do. Actually, it doesn't do any more consing than the macro definition, because &REST arguments are stack-allocated on Symbolics machines (in generally-agreed-on violation of CLtL). Even in Lucid's implementation this definition would not cons, because the ignored rest argument is never created in the first place. The compiler open-codes PROG1 invocations, so this is only used in the interpreter. Does this seem valid? The only implementation leeway CLtL mentions is that macros may be implemented as special forms, so long as an equivalent macro definition is also made available; it doesn't specifically mention implementing macros as functions (probably because the developers thought that none of them COULD be implemented as functions). I don't see how this could cause any code to fail. barmar Someone writing a cross-compiler or other codewalking tool that did macroexpansion might be surprised that PROG1 was not expanded. This might not be a problem if the result were going to run in the same environment, but it could cause trouble if it were going to be used in an environment where PROG1 is a macro. CLtL is silent on this topic (like many others). It is not explicitly prohibited, nor is it explicitly permitted. This raises a meta-question: If something is not mentioned, does that mean it is permitted, or does that mean it is prohibited? I think it must be the former, since CLtL defines a "core" language, which may be extended by the implementor. The cleanup committee has tried to fill many of these holes, but it is impossible to deal with all of them. It is safe to say that ambiguities will be discovered as long as there are prople using Common Lisp. Here are some choice ones, in increasing order of bizarreness: Is it OK to define Common Lisp functions with extra optional or keyword parameters, with system dependent meanings? E.g. Lucid's COMPILE-FILE has several keyword arguments not mentioned in CLtL. Is it OK to return extra values from Common Lisp functions? Is it OK to define the behavior of functions on datatypes not explicitly permitted in CLtL? For example, suppose I defined + on vectors to do componentwise addition on the elements? Arguments to + "must" be numbers, meaning that it "is an error" to supply anything other than numbers, meaning that anything can happen when you supply arguments other than numbers. Suppose an implementation printed >>Attention: Taking CAR of (1 2 3)! every time CAR was called. I don't suppose many people would use it, but would it be a legal Common Lisp implementation?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 08:51:07 EST Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 4 Jan 89 05:37:09 PST Received: from vax5.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B) id AA05758; Wed, 4 Jan 89 08:38:09 est Message-Id: <8901041338.AA05758@crash.cs.umass.edu> Date: Wed, 4 Jan 89 08:37 EST From: David Forster Subject: re: commonlisp types To: common-lisp@sail.stanford.EDU X-Vms-To: IN%"common-lisp@sail.stanford.edu" The TI Explorer (4.2) is one of your problem cases -- it applies the flet'd function in the `satisfies' clause, instead of the defun'd one.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 4 Jan 89 04:15:25 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 4 Jan 89 01:01:59 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA04028g; Wed, 4 Jan 89 00:56:44 PST Received: by bhopal id AA01403g; Wed, 4 Jan 89 00:58:57 PST Date: Wed, 4 Jan 89 00:58:57 PST From: Jon L White Message-Id: <8901040858.AA01403@bhopal> To: RWK@F.ILA.Dialnet.Symbolics.COM Cc: common-lisp@sail.stanford.edu In-Reply-To: Robert W. Kerns's message of Tue, 3 Jan 89 05:35 EST <19890103103558.4.RWK@F.ILA.Dialnet.Symbolics.COM> Subject: commonlisp types re: How do you define "valid type specifier"? Very syntactically. I think its perfectly acceptable to have a set of combination rules for making "words" in the type-specifier syntax, even though some such "words" would be gibberish. The important thing is that base-level types -- those defined in CLtL -- along with DEFSTRUCT extensions be recognizable. They don't have the problems that SATISFIES generates, or that a broken user definition generates (such as your DEFTYPE FOO example). By the bye, on another note, I haven't seen any implementation that has the bug Kent wondered about earlier: (defun bar (x) (symbolp x)) (defun foo (x) (flet ((bar (y) (integerp y))) (typep x '(satisfies bar)))) (foo 'x) The correct answer is T, but I bet a lot of implementations return NIL in compiled code. Anyone know of an implementation for which this fails? -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Jan 89 20:29:56 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 3 Jan 89 17:14:00 PST Return-Path: Received: from sauron.think.com by Think.COM; Tue, 3 Jan 89 19:44:12 EST Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 3 Jan 89 20:10:55 EST Date: Tue, 3 Jan 89 20:10 EST From: Barry Margolin Subject: PROG1 as a function To: common-lisp@sail.stanford.edu Message-Id: <19890104011056.6.BARMAR@OCCAM.THINK.COM> One of our users noticed today that Symbolics defines PROG1 as a function, rather than as a macro as CLtL specifies. The definition is essentially (defun prog1 (first-form &rest rest-forms) (declare (ignore rest-forms)) first-form) This works because CL requires left-to-right evaluation of function arguments; it just does a bit more consing than a macro implementation would need to do. The compiler open-codes PROG1 invocations, so this is only used in the interpreter. Does this seem valid? The only implementation leeway CLtL mentions is that macros may be implemented as special forms, so long as an equivalent macro definition is also made available; it doesn't specifically mention implementing macros as functions (probably because the developers thought that none of them COULD be implemented as functions). I don't see how this could cause any code to fail. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 3 Jan 89 06:57:46 EST Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 3 Jan 89 03:39:54 PST Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 305296; 3 Jan 89 06:37:40 EST Date: Tue, 3 Jan 89 05:35 EST From: Robert W. Kerns Subject: commonlisp types To: jonl%lucid.com@RIVERSIDE.SCRC.SYMBOLICS.COM, common-lisp%sail.stanford.edu@RIVERSIDE.SCRC.SYMBOLICS.COM In-Reply-To: <8812070546.AA11501@bhopal> Supersedes: <19890103090720.6.RWK@F.ILA.Dialnet.Symbolics.COM> Comments: Retransmission of failed mail. Message-ID: <19890103103558.4.RWK@F.ILA.Dialnet.Symbolics.COM> Date: Tue, 6 Dec 88 21:46:27 PST From: Jon L White re: There seems to be nothing in CLtL that answers the question: "is x a legal type specifier?" At the meeting that founded the X3J13 committee (on 6-Dec-85), Guy Steele circulated a list of "non-controversial issues" and "Clarifications" which included the following addition [typos faithfully reproduced]: "(*) 51 Add a newefunction TYPE-SPECIFIER-P that is true of valid type specifiers and fals of all other Lisp objects. Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over time." Sad to say, this and many other "non-controversial" items included in Guy's list of "Clarifications", has never been brought up in the X3J13 "Cleanup" subcommittee. However, Lucid's 3.0 release includes such a function. How do you define "valid type specifier"? (deftype foo (x) (car x)) (typep 'yow '(foo a)) ==> Error taking CAR of the symbol A. (type-specifier-p '(foo a)) ==> ? I would guess probably T, but then, how do you word the definition? If not, how do you define it?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Jan 89 15:53:45 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 2 Jan 89 12:37:56 PST Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 514019; Mon 2-Jan-89 15:35:56 EST Date: Mon, 2 Jan 89 15:35 EST From: David A. Moon Subject: commonlisp types To: Kent M Pitman cc: gls@Think.COM, jwz@spice.cs.cmu.edu, common-lisp@sail.stanford.edu In-Reply-To: <881222151736.1.KMP@BOBOLINK.SCRC.Symbolics.COM> Message-ID: <19890102203526.6.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Thu, 22 Dec 88 15:17 EST From: Kent M Pitman Date: Fri, 2 Dec 88 11:33:22 EST From: Guy Steele Date: Fri, 2 Dec 1988 00:40-EST From: Jamie.Zawinski ... Can someone explain the rationale behind forcing SATISFIES to accept only function-names and not lambda expressions? .... Fyi, it turns out this rationale doesn't hold as much water as you'd think. Consider: (defun bar (x) (symbolp x)) (defun foo (x) (flet ((bar (y) (integerp y))) (typep x '(satisfies bar)))) (foo 'x) The correct answer is T, but I bet a lot of implementations return NIL in compiled code. .... The real truth is that we thought the scoping problems were limited to LAMBDA expressions because we weren't used to reasoning about FLET, which was a new construct at the time we designed CL. If we had it to do over, I'd certainly be lobbying strongly for permitting lambda expressions. You're right. I think what really happened is not that we weren't used to FLET, but that FLET and LABELS were added to the language after type-specifiers had been designed, and the full ramifications of FLET on the rest of the language were not explored at the time it was added.  Received: from SAIL.Stanford.EDU (TCP 4425400302) by AI.AI.MIT.EDU 27 Dec 88 11:39:00 EST Received: from gateway.mitre.org by SAIL.Stanford.EDU with TCP; 27 Dec 88 08:19:42 PST Received: by gateway.mitre.org (5.54/SMI-2.2) id AA10060; Tue, 27 Dec 88 11:15:04 EST Return-Path: Received: by chance.mitre.org (3.2/SMI-2.2) id AA21082; Tue, 27 Dec 88 11:12:23 EST From: howell%community-chest.mitre.org@gateway.mitre.org Message-Id: <8812271612.AA21082@chance.mitre.org> To: ailist@ai.ai.mit.edu, common-lisp@sail.stanford.edu, slug@warbucks.ai.sri.com Cc: howell@mitre.ARPA Subject: Experiences porting applications from Symbolics Date: Tue, 27 Dec 88 11:12:21 -0500 I'm trying to make a quick and dirty estimate of the level of effort required to port a local application from the Symbolics to other hosts (probably a microvax II or an HP 9000). Any experiences with such a port (to any other hosts, not just the HP or microVax) would be very helpful. For example, did you encounter problems with variant semantics in different Common Lisp compilers? What kind of support did the new host provide for mouse-sensitive bit-mapped graphics, and for access to them? Did you find that your application depended on Symbolics-provided function libraries or "OS services", or was your application relatively host-independent? Any big "gotchas" that you didn't expect? Thanks in advance for any replies. Chuck Howell, MITRE howell@mitre.mitre.org (703) 883-6080  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 22 Dec 88 15:37:29 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Dec 88 12:18:57 PST Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 511560; Thu 22-Dec-88 15:17:50 EST Date: Thu, 22 Dec 88 15:17 EST From: Kent M Pitman Subject: commonlisp types To: gls@Think.COM cc: jwz@spice.cs.cmu.edu, common-lisp@sail.stanford.edu In-Reply-To: <8812021633.AA05964@verdi.think.com> Message-ID: <881222151736.1.KMP@BOBOLINK.SCRC.Symbolics.COM> Date: Fri, 2 Dec 88 11:33:22 EST From: Guy Steele Date: Fri, 2 Dec 1988 00:40-EST From: Jamie.Zawinski ... Can someone explain the rationale behind forcing SATISFIES to accept only function-names and not lambda expressions? I can see that the compiler could have special knowledge about such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded "to avoid scoping problems." Consider (defun bazola (linguini pop-tarts) (declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts)) ...) I'm trying to say that pop-tarts is always smaller in value than linguini. The lambda expression appears lexically within the binding of linguini, so one might expect that the free reference to linguini is legitimate. But it can't work. Similarly this cannot work: (defun bazola (linguini pop-tarts) (assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini))))) ...) [Of course, this can be rendered instead as (defun bazola (linguini pop-tarts) (assert (< pop-tarts linguini)) ...) but that is beside the point.] One might conceivably argue that SATISFIES should allow an actual function and not just a name; then one might try (defun bazola (linguini pop-tarts) (assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini))))) ...) but this approach doesn't help the declaration case. It's a basic problem of compile-time versus run-time execution. --Guy Fyi, it turns out this rationale doesn't hold as much water as you'd think. Consider: (defun bar (x) (symbolp x)) (defun foo (x) (flet ((bar (y) (integerp y))) (typep x '(satisfies bar)))) (foo 'x) The correct answer is T, but I bet a lot of implementations return NIL in compiled code. Anyway, my main point is that the reason for prohibiting lambda expressions isn't that they're not meaningful, only that they're hard to reason about. But since an analogous argument can be made for symbols, the rationale breaks down. Since (SATISFIES BAR) means that (FUNCALL (SYMBOL-FUNCTION 'BAR) ...) is true, not that (FUNCALL #'BAR ...) is true, then it follows that (SATISFIES (LAMBDA (X) (AND (BAR X) (BAZ X)))) means (FUNCALL (EVAL '#'(LAMBDA (X) (AND (BAR X) (BAZ X)))) ...) is true, not that (FUNCALL #'(LAMBDA (X) (AND (BAR X) (BAZ X))) ...) is true. The real truth is that we thought the scoping problems were limited to LAMBDA expressions because we weren't used to reasoning about FLET, which was a new construct at the time we designed CL. If we had it to do over, I'd certainly be lobbying strongly for permitting lambda expressions. The Common-Lisp mailing list doesn't have the authority to change the language, so I'll save any proposals to change things for other forums. But I did want to publicly debunk the myth behind this design decision. Btw, if LAMBDA expressions -were- permitted, the BAZOLA example you suggest could, in addition to the more obvious way you cite, be written as: (defun bazola (linguini pop-tarts) (declare (special linguini)) (assert (typep pop-tarts '(satisfies (lambda (x) (declare (special linguini)) (< x linguini))))) ...) This works even if you open code it in the obvious way, though it has the disadvantage that figuring out that the SPECIAL declaration was needed only for the sake of the transition into the SATISFIES and not for some function called within the opened LAMBDA may be tricky. So the open-coded form may do a needless special bind in complex cases involving calls to user-defined predicates.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Dec 88 21:35:56 EST Received: from trwrb.dsd.trw.com (TRWRB.TRW.COM) by SAIL.Stanford.EDU with TCP; 16 Dec 88 18:21:13 PST Received: by trwrb.dsd.trw.com (5.51/1.36) id AA14762; Fri, 16 Dec 88 18:18:22 PST From: smpvax1!daemon@trwrb.dsd.trw.com Received: by smpvax1.inference.com (3.2/SMI-3.2 SBB's version) id AA07290; Fri, 16 Dec 88 17:30:56 PST Date: Fri, 16 Dec 88 17:30:56 PST Message-Id: <8812170130.AA07290@smpvax1.inference.com> To: Dave.Touretzky\@cs.cmu.edu@trwrb.dsd.trw.com, ucbvax!lucid.com!jonl@trwrb.dsd.trw.com Cc: common-lisp\@sail.stanford.edu@trwrb.dsd.trw.com In-Reply-To: Jon L White's message of Fri, 16 Dec 88 01:22:08 PST <8812160922.AA20998@bhopal> Subject: file loading query re: 1. Anybody know a *portable* trick I can use to get embedded calls to LOAD to use the parent file's pathname as a default? You needn't be a privileged implementor to use Lucid's idea. This should be portable: (defvar *my-load-pathname* nil) (defun my-load (partial-path) (let ((*my-load-pathname* (merge-pathnames partial-path *my-load-pathname*))) (load *my-load-pathname*))) and replace all calls to load in files with calls to my-load, e.g., (my-load "What-a-moaning") A more general thing involving twiddling the prefix of a directory tree from which embedded loads will occur in various subdirectories might be (defun load-from-subtree (partial-path path-function) (let ((*my-load-pathname* (funcall path-function partial-path *my-load-pathname*))) (load *my-load-pathname*))) and replace embedded load calls with load-from-subtree. Typically the path-function will concatenate the directories of *my-load-pathname* and partial-path, or something. At least on Lucid 3.0, merge-pathnames serves as such a function, as in (merge-pathnames "arith/bignum" "~/broken/mork.bin"). Jeff Greif Inference Corp.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Dec 88 11:56:36 EST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Dec 88 08:43:29 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA27569; Fri, 16 Dec 88 08:45:46 PST Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA02972; Fri, 16 Dec 88 08:42:27 PST Received: by clam.sun.com (3.2/SMI-3.2) id AA17011; Fri, 16 Dec 88 08:43:24 PST Date: Fri, 16 Dec 88 08:43:24 PST From: cperdue@Sun.COM (Cris Perdue) Message-Id: <8812161643.AA17011@clam.sun.com> To: cl-compiler@sail.stanford.edu, donc@vaxa.isi.edu Subject: Re: dumping weird objects to compiled files Cc: common-lisp@sail.stanford.edu, lwolf%franz.uucp@berkeley.edu Hi Don! I'm working on a proposal on this exact issue, i.e. what Common Lisp is supposed to do about (quoted) constants in compiled files. There are big holes in the definition of Common Lisp today concerning compilation, and this is one of them. To answer one of your questions, no you definitely cannot expect your constants to be PRINTed into compiled files. Most implementations use some binary representation of data. There is interest in supporting user-defined types (structures and classes) with user-definable dumpers, but it's just too much work for me to personally try to address that. Hopefully some good facility will get defined. There is also interest in something comparable to #, that is not a readmacro, so you can sensibly generate them in programs and at least one proposal for that. You can mail to me for more information. -Cris  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Dec 88 10:50:36 EST Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Dec 88 07:32:56 PST Received: from defun.utah.edu by cs.utah.edu (5.59/utah-2.1-cs) id AA06704; Fri, 16 Dec 88 08:31:57 MST Received: by defun.utah.edu (5.59/utah-2.0-leaf) id AA05675; Fri, 16 Dec 88 08:31:53 MST From: sandra%defun@cs.utah.edu (Sandra J Loosemore) Message-Id: <8812161531.AA05675@defun.utah.edu> Date: Fri, 16 Dec 88 08:31:51 MST Subject: Re: dumping weird objects to compiled files To: Don Cohen Cc: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu, lwolf%franz.uucp@berkeley.edu In-Reply-To: Don Cohen , Thu, 15 Dec 88 18:52:28 PST The cl-compiler subcommittee is in the midst of preparing a set of elaborate proposals to submit to X3J13 to detail exactly what kinds of constant objects may be compiled. We do think it is important for the ANSI standard to say more than CLtL does about this. At the moment we appear to be heading towards the conclusion that the dump/load transformation on structures created with DEFSTRUCT ought to always create a structure isomorphic to the original, regardless of whether or not that structure type has a user-supplied :PRINT-FUNCTION. However, we have also talked about something similar to the dump/load protocol you describe in the context of arbitrary CLOS objects. -Sandra -------  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Dec 88 04:33:49 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 16 Dec 88 01:22:59 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00971g; Fri, 16 Dec 88 01:20:08 PST Received: by bhopal id AA20998g; Fri, 16 Dec 88 01:22:08 PST Date: Fri, 16 Dec 88 01:22:08 PST From: Jon L White Message-Id: <8812160922.AA20998@bhopal> To: Dave.Touretzky@cs.cmu.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: Dave.Touretzky@B.GP.CS.CMU.EDU's message of Tue, 13 Dec 88 20:04:24 EST <2131.598064664@DST.BOLTZ.CS.CMU.EDU> Subject: file loading query re: 1. Anybody know a *portable* trick I can use to get embedded calls to LOAD to use the parent file's pathname as a default? I doubt that there's a portable trick. Lucid Common Lisp supports an extension as follows: (defvar *load-pathname* nil "During a load, this is bound to the pathname of the file being loaded.") and ocasionally it is used to find out what directory the currently loading file is on, so that a related file can be loaded from the same directory. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Dec 88 22:07:40 EST Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 15 Dec 88 18:53:10 PST Posted-Date: Thu, 15 Dec 88 18:52:28 PST Message-Id: <8812160252.AA06530@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA06530; Thu, 15 Dec 88 18:52:31 PST To: common-lisp@sail.stanford.edu, cl-compiler@sail.stanford.edu Cc: lwolf%franz.uucp@berkeley.edu Subject: dumping weird objects to compiled files Date: Thu, 15 Dec 88 18:52:28 PST From: Don Cohen The commonlisp spec is quite vague on what exactly the compiler should do and provides no control over how or whether strange objects can be dumped at all. However, in the case of structures it does provide for a print function. Suppose I have a function F that uses a macro M which expands into some structure of type S. 1. If I give S a print function, can I expect that when I compile F to a file, that print function will be used to write something to the compiled file that will be read to return the "corresponding" object when the file is loaded? (I'm interested in justifications for either answer.) The other possibility is that the compiler would ignore the print function and dump something that would, when loaded, create a structure of type S and fill its slots with objects that were recursively dumped. If I could count on my print function being used, I could arrange for it to print something that would "do the right thing". 2. If you don't think that my expectation is justified, do you think the commonlisp spec ought to say that it is (thereby making it so). This "trick" would allow us to write a macro that allows macros to generate the analog of #, which I think is a feature sorely missed in commonlisp. This in turn would go a long way toward solving what I regard as a problem with the spec - that EQUAL values may be identified. This is a solution just because it returns control over what things are EQ to the user, who knows which things he wants to be EQ, which things he does NOT want EQ and which don't matter.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 15 Dec 88 20:31:18 EST Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 15 Dec 88 17:20:23 PST Date: Thu, 15 Dec 88 09:55:14 PST From: Thom Linden To: Common Lisp mailing Message-ID: <881215.095514.baggins@IBM.com> Subject: WG16 document N31, "Working documents on CALLING MECHANISMS..." I have a copy of the document Jeff mentioned and will bring it to the Jan. meeting. Thom  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Dec 88 19:27:40 EST Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 14 Dec 88 16:19:18 PST Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 14 Dec 88 19:17:08 EST To: common-lisp@sail.stanford.EDU Reply-To: Dave.Touretzky@cs.cmu.edu Subject: Re: load defaults In-reply-to: Your message of Wed, 14 Dec 88 11:11:00 -0500. <8812141614.AA02232@crash.cs.umass.edu> Date: Wed, 14 Dec 88 19:16:51 EST Message-ID: <3154.598148211@DST.BOLTZ.CS.CMU.EDU> From: Dave.Touretzky@B.GP.CS.CMU.EDU > Date: Wed, 14 Dec 88 11:11 EST > From: MURRAY@cs.umass.EDU > > There is no portable way to find out what pathname is currently being > loaded. The portable way to get your desired behavior is simply to > define your own load function that will bind *DEFAULT-PATHNAME-DEFAULTS* > to the file it is loading before it calls the real load. > (defun default-load (input &rest args) > (let ((*default-pathname-defaults* (merge-pathnames input))) > (apply 'load *default-pathname-defaults* args))) This is a nice idea, but it doesn't solve my problem. The user would have to type in the whole definition before he could use it to load the header file I referred to. I want to avoid inconveniencing the user; he should be able to just start up a fresh Lisp, LOAD a single header file, and have everything else happen automatically. I like KMP's proposals. I like the second one best: have separate variables for files being loaded and files being compiled, and use them to maintain a stack so we can see the nesting of loads within files. -- Dave  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Dec 88 13:09:59 EST Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 14 Dec 88 09:59:23 PST Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0) id AA28669; Wed, 14 Dec 88 09:59:57 PST Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0) id AA27264; Wed, 14 Dec 88 09:56:35 PST Received: by clam.sun.com (3.2/SMI-3.2) id AA14360; Wed, 14 Dec 88 09:57:31 PST Date: Wed, 14 Dec 88 09:57:31 PST From: cperdue@Sun.COM (Cris Perdue) Message-Id: <8812141757.AA14360@clam.sun.com> To: Dave.Touretzky@B.GP.CS.CMU.EDU, MURRAY@cs.umass.EDU, common-lisp@sail.stanford.EDU Subject: RE: load defaults Some implementations of Common Lisp include a special variable with a name like *source-pathname*, which is bound appropriately by LOAD. This supports what is commonly known as "source code recording" and if added to Common Lisp would meet needs such as Touretzky's. We have found need for this at Sun and would be happy to see such a thing in the language at some time. -Cris  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Dec 88 11:32:37 EST Received: from crash.cs.umass.edu ([128.119.40.235]) by SAIL.Stanford.EDU with TCP; 14 Dec 88 08:13:15 PST Received: from vax2.cs.umass.edu by crash.cs.umass.edu (5.59/Ultrix2.0-B) id AA02232; Wed, 14 Dec 88 11:14:26 est Message-Id: <8812141614.AA02232@crash.cs.umass.edu> Date: Wed, 14 Dec 88 11:11 EST From: MURRAY@cs.umass.EDU Subject: RE: load defaults To: common-lisp@sail.stanford.EDU X-Vms-To: IN%"common-lisp@sail.stanford.EDU" > From: Dave.Touretzky@B.GP.CS.CMU.EDU >I have a problem with the way Common Lisp says pathname defaults should be > handled during load... My initial reaction is that you should be using some sort of defsystem, which gives you much more control over sets of files. But maybe you're trying to run bare-bones. >1. Anybody know a *portable* trick I can use to get embedded calls to LOAD >to use the parent file's pathname as a default? There is no portable way to find out what pathname is currently being loaded. The portable way to get your desired behavior is simply to define your own load function that will bind *DEFAULT-PATHNAME-DEFAULTS* to the file it is loading before it calls the real load. (defun default-load (input &rest args) (let ((*default-pathname-defaults* (merge-pathnames input))) (apply 'load *default-pathname-defaults* args))) >2. How terrible would it be for LOAD to rebind *DEFAULT-PATHNAME-DEFAULTS* ? Probably not too terrible, but it does create another instance of a problem that some people have complained about. By having LOAD bind a special variable, it make it impossible to have the contents of a file side-effect that variable after the load. This is a current problem with *package*. >3. Alternatively, what would people think of adding a :PARENT-PATH keyword >to LOAD. With a value of T this keyword would mean "if this is an embedded >load, get default pathname information from the pathname of the parent >file" ? Surely you jest! Kelly Murray  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Dec 88 00:19:03 EST Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 13 Dec 88 21:07:27 PST Received: from decwrl.dec.com by labrea.stanford.edu with TCP; Tue, 13 Dec 88 21:06:07 PST Received: by decwrl.dec.com (5.54.5/4.7.34) for labrea!sail.stanford.edu!common-lisp; id AA07389; Tue, 13 Dec 88 21:06:33 PST Received: by pyramid.pyramid.com (5.51/OSx4.4-880707) id AA14035; Tue, 13 Dec 88 18:58:33 PST Received: by neat.ai.toronto.edu with UUCP id 38064; Tue, 13 Dec 88 16:21:52 EST Received: by nexus.yorku.ca with UUCP id 28713; Tue, 13 Dec 88 13:14:31 EST Received: from istsai.yorku.ca by ists.yorku.ca (3.2/smail2.5/15-05-88) id AA09454; Tue, 13 Dec 88 02:45:21 EST Date: Tue, 13 Dec 88 02:46:37 EST From: mike@ists.yorku.ca Message-Id: <8812130746.AA03313@istsai.yorku.ca> To: bill@red.ipsa.dnd.ca Cc: common-lisp@sail.stanford.edu In-Reply-To: IN%"bill@red.ipsa.dnd.ca"'s message of 29 NOV 88 11:47 EST Subject: Common Lisp for SUNS I have some experiences. Give me a call at 416-736-5611 if you wnat to talk. Mike.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Dec 88 20:19:10 EST Received: from DST.BOLTZ.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 13 Dec 88 17:06:48 PST Received: from DST.BOLTZ.CS.CMU.EDU by DST.BOLTZ.CS.CMU.EDU; 13 Dec 88 20:05:13 EST To: common-lisp@sail.stanford.edu Reply-To: Dave.Touretzky@cs.cmu.edu Subject: file loading query Date: Tue, 13 Dec 88 20:04:24 EST Message-ID: <2131.598064664@DST.BOLTZ.CS.CMU.EDU> From: Dave.Touretzky@B.GP.CS.CMU.EDU I have a problem with the way Common Lisp says pathname defaults should be handled during load. I have a software system structured as a header file FOO.LISP that loads various component files BAR1, BAR2, BAR3, etc. Some of the component files may in turn load other components. Now, I actually have several versions of this system, each living in its own directory. Whenever I make a new version due to an experimental change to one component, or to test out the code generated by a new compiler, I put it in its own directory. The problem is, how do I get the calls to LOAD that appear in FOO, and in the files loaded by FOO, to look in whatever directory the header file FOO was loaded from? The current definition of LOAD looks at *DEFAULT-PATHNAME-DEFAULTS*, so one solution would be to set this variable manually every time, before loading FOO. That's a real nuisance, which I'd like to avoid if possible. Another possibility would be to add a line at the beginning of FOO to set *DEFAULT-PATHNAME-DEFAULTS*, but that also loses because (a) every time I made a new copy of the software I would have to edit FOO, and (b) when I want to replace one version of the software with another, as when replacing the contents of directory old/ with current/ and current/ with new/, I would have to make sure NOT to copy the header file. The potential for problems if the header file is accidentally copied is too great. In some implementations (either the Symbolics or the TI machine I worked on about 2 years ago), a call to LOAD embedded in a file appeared to get its pathname defaults from the pathname of the parent file being loaded, but this doesn't appear to be part of the Common Lisp standard. In other implementations I seem to recall LOAD rebinding *STANDARD-INPUT*, so I could snarf the actual pathname information from there. But in CMU Common Lisp, LOAD does not rebind *STANDARD-INPUT*, and CLtL doesn't seem to require this. So... 1. Anybody know a *portable* trick I can use to get embedded calls to LOAD to use the parent file's pathname as a default? 2. How terrible would it be for LOAD to rebind *DEFAULT-PATHNAME-DEFAULTS* ? 3. Alternatively, what would people think of adding a :PARENT-PATH keyword to LOAD. With a value of T this keyword would mean "if this is an embedded load, get default pathname information from the pathname of the parent file" ? -- Dave  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Dec 88 17:55:05 EST Received: from IBM.COM by SAIL.Stanford.EDU with TCP; 13 Dec 88 14:42:52 PST Date: Tue, 13 Dec 88 12:54:23 PST From: Thom Linden To: Common Lisp mailing Message-ID: <881213.125423.baggins@IBM.com> Subject: foreign function Even though the bulk of participants in x3j13 are moving into the "editorial" phase of the process, I see no reason why a new subcommittee shouldn't be formed. It's probably unlikely that anything would make it into the first release of the std but it is reasonable for folks to begin work on next release items as with, for example, some of the iteration committee activity. Another example might be vol3 of CLOS. We shouldn't be pressed prematurely into incorporating everything into the 1989 draft. At the Jan meeting, someone should suggest this subcommittee be formed and simply begin the discussion with those of similar interest.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Dec 88 10:52:04 EST Received: from CENTRO.SOAR.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 7 Dec 88 07:39:44 PST Received: from CENTRO.SOAR.CS.CMU.EDU by CENTRO.SOAR.CS.CMU.EDU; 7 Dec 88 00:15:23 EST To: Common-Lisp@SAIL.STANFORD.EDU cc: soar-archive@CENTRO.SOAR.CS.CMU.EDU Subject: #+ and *read-supress* Date: Wed, 07 Dec 88 00:14:22 EST Message-ID: <22302.597474862@CENTRO.SOAR.CS.CMU.EDU> From: Brian.Milnes@CENTRO.SOAR.CS.CMU.EDU The Soar project is considering adopting "," as part of our language's syntax. This is a dangerous move at best in a Common Lisp implementation, but it would be quite nice for our purposes. While the new version of Soar is under development, this read table modification to comma is on a *feature*, :DSM. When I try and run my test code over the old style code (i.e. #-:DSM),"#+:DSM form", where form contains a comma, form will not read. Page 359 says that *read-supress* is lambda bound non-nil during my #+:DSM read of form when :DSM is not a member of *features*. Pages 345 and 346 of Steele's CLtL document *read-supress* and page 346 says, "Note that, no matter what the value of *read-supress*, parentheses still continue to delimit (and construct) lists; the #( construction continues to delimit vectors; and comments, strings and the quote and backquote constructions continue to be interpreted properly. Furthermore, such situations as '), #<, #) and # continue to signal errors." It is clear to me that we need parentheses, #(, comments and strings to read correctly so that #+/- can delimit form. It also seems nice to me that the usual reader errors will occur, such as '), #< and #). What I'm missing is the rationale for having quote and backquote (and its "," macro) still in operation. It would be nicer in this case if commas were read over. Perhaps a rationale note should be added by the clean up committee, or the quote and/or backquote should be removed from *read-supress*. Thanks, Brian Milnes (Milnes@centro.soar.cs.cmu.edu)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 7 Dec 88 01:25:10 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 6 Dec 88 21:46:59 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00869g; Tue, 6 Dec 88 21:44:34 PST Received: by bhopal id AA11501g; Tue, 6 Dec 88 21:46:27 PST Date: Tue, 6 Dec 88 21:46:27 PST From: Jon L White Message-Id: <8812070546.AA11501@bhopal> To: donc@vaxa.isi.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: Don Cohen's message of Wed, 30 Nov 88 18:55:38 PST <8812010255.AA17146@vaxa.isi.edu> Subject: commonlisp types re: There seems to be nothing in CLtL that answers the question: "is x a legal type specifier?" At the meeting that founded the X3J13 committee (on 6-Dec-85), Guy Steele circulated a list of "non-controversial issues" and "Clarifications" which included the following addition [typos faithfully reproduced]: "(*) 51 Add a newefunction TYPE-SPECIFIER-P that is true of valid type specifiers and fals of all other Lisp objects. Note that the use of DEFSTRUCT and DEFTYPE can change the behavior of TYPE-SPECIFIER-P over time." Sad to say, this and many other "non-controversial" items included in Guy's list of "Clarifications", has never been brought up in the X3J13 "Cleanup" subcommittee. However, Lucid's 3.0 release includes such a function. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Dec 88 21:56:02 EST Received: from gateway.mitre.org by SAIL.Stanford.EDU with TCP; 5 Dec 88 18:36:26 PST Received: by gateway.mitre.org (5.54/SMI-2.2) id AA06609; Mon, 5 Dec 88 21:33:10 EST Return-Path: Received: from localhost.mitre.org by community-chest.mitre.org (3.2/SMI-2.2) id AA07696; Mon, 5 Dec 88 21:31:26 EST Message-Id: <8812060231.AA07696@community-chest.mitre.org> To: common-lisp@sail.stanford.edu, ailist@ai.ai.mit.edu Subject: CLtL for HP9000? Date: Mon, 05 Dec 88 21:31:25 -0500 From: howell%community-chest.mitre.org@gateway.mitre.org Are there implementations of Common Lisp available for the HP 9000 (models 330/350/370, if it matters) under UNIX? How about X-Windows, and CLX/CLUE for the same configuration? Thanks for your help, Chuck Howell The MITRE Corporation, Mail Stop W418 7525 Colshire Drive, McLean, VA 22102 NET: howell@mitre.arpa or howell%community-chest.mitre.org@gateway.mitre.org  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 5 Dec 88 02:31:42 EST Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 4 Dec 88 23:18:46 PST Received: by ucbarpa.Berkeley.EDU (5.61/1.29) id AA17362; Sun, 4 Dec 88 23:17:50 PST Received: from frisky by franz (3.2/3.14) id AA10238; Sun, 4 Dec 88 22:55:12 PST Received: by frisky (3.2/3.14) id AA14271; Sun, 4 Dec 88 22:52:47 PST From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8812050652.AA14271@frisky> To: franz!ucbarpa!labrea.stanford.edu!ibuki!dbp (David Posner) Cc: franz!sail.stanford.edu!common-lisp Subject: Re: Common Lisp for SUNS In-Reply-To: Your message of Thu, 01 Dec 88 15:50:57 PST. <8812012350.AA12633@ibuki.UUCP> Date: Sun, 04 Dec 88 22:52:46 PST I'm sorry if you got the impression that I was criticizing the authors of KCL. I'm sure that they are excellent programmers and have developed the best possible C-based Lisp system. What I do still question is the use of C as the intermediate language for a Lisp compiler. I would like the put this question to Professors Yuasa and Hagiya, "If your job was to write the *best possible* Lisp system for a given machine, and you were allowed a reasonable amount of time to do so, would you choose C as the intermediate language or would you go directly to the machine language?" My answer would be of course to go to machine language and I suspect that they would agree. However, if the goal is to write a Lisp that is a portable as possible and where efficiency is important only as long as it doesn't get in the way of portability, then using C may be a good idea. C was a good match for the PDP-11 but on every machine since then it has been a compromise, with the nice new features of the each architecture frequently being inaccessible to the C programmer (e.g. the tagged add's and the global registers of the sun4). If your goal is the *best possible* Lisp then you should use all the features of the architecture that are appropriate for Lisp. [Your conclusion on the uselessness of global registers in the sun4 only looked at the first-order effects. Yes, you don't need a global pointer if you use direct linked calls, however the use of a global pointer gives one position independent code which permits the system to have a copying garbage collector (without maintaining relocation tables) which has important benefits in paging and so on and so on] You said that your compiler does well when everything is declared and speed=3 and safety=0. This situation occurs in less than 1% of the code I write. I believe that Lisp has to work well in the mode where the user just wants the speedup the compiler provides and doesn't want to lose the interactive detection of errors he would get from running the code interpreted. If the Lisp does a good enough job at inlining type checks the user will be satisfied with the performance and won't even crank up the speed and lower the safety. Inline type checking is a case where there are clever hacks (unexpressible in C) than implementor can use. Yes, it does take time to port Lisp to a machine if you have to study the architecture in detail and write in machine code. However, computer manufacturers are convinced that Lisp is an important language to offer so typically they supply machines to Lisp implementation companies well before the the machines are introduced to the public. Thus a C-based implementation won't 'get to market' that much earlier (if any earlier). As for architectures that existed before Common Lisp 'took off', there are still a few important ones without 'native' Lisp ports but that number is shrinking and will be close to zero in six months to a year. I don't mean to put down anyone or any company. Thinking back I realize that I've spent a third of my life implementing Lisp on stock hardware machines, so I guess that I've developed some strong opinions during that time. Sorry for being so longwinded. John Foderaro Franz Inc.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 88 11:56:09 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:36:41 PST Received: from fafnir.think.com by Think.COM; Fri, 2 Dec 88 11:13:42 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Fri, 2 Dec 88 11:34:51 EST Received: by verdi.think.com; Fri, 2 Dec 88 11:33:22 EST Date: Fri, 2 Dec 88 11:33:22 EST From: Guy Steele Message-Id: <8812021633.AA05964@verdi.think.com> To: jwz@spice.cs.cmu.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: Jamie.Zawinski's message of Fri, 2 Dec 1988 00:40-EST <8812020545.AA12869@Think.COM> Subject: commonlisp types Date: Fri, 2 Dec 1988 00:40-EST From: Jamie.Zawinski ... Can someone explain the rationale behind forcing SATISFIES to accept only function-names and not lambda expressions? I can see that the compiler could have special knowledge about such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded "to avoid scoping problems." Consider (defun bazola (linguini pop-tarts) (declare (type (satisfies (lambda (x) (< x linguini))) pop-tarts)) ...) I'm trying to say that pop-tarts is always smaller in value than linguini. The lambda expression appears lexically within the binding of linguini, so one might expect that the free reference to linguini is legitimate. But it can't work. Similarly this cannot work: (defun bazola (linguini pop-tarts) (assert (typep pop-tarts '(satisfies (lambda (x) (< x linguini))))) ...) [Of course, this can be rendered instead as (defun bazola (linguini pop-tarts) (assert (< pop-tarts linguini)) ...) but that is beside the point.] One might conceivably argue that SATISFIES should allow an actual function and not just a name; then one might try (defun bazola (linguini pop-tarts) (assert (typep pop-tarts `(satisfies ,(lambda (x) (< x linguini))))) ...) but this approach doesn't help the declaration case. It's a basic problem of compile-time versus run-time execution. --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 88 11:31:25 EST Received: from labrea.stanford.edu by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:10:16 PST Received: by labrea.stanford.edu; Fri, 2 Dec 88 08:09:07 PST Received: by ibuki.UUCP (5.52/4.7) id AA12633; Thu, 1 Dec 88 15:50:57 PST Date: Thu, 1 Dec 88 15:50:57 PST From: ibuki!dbp@labrea.stanford.edu (David Posner) Message-Id: <8812012350.AA12633@ibuki.UUCP> To: common-lisp@sail.stanford.edu Subject: Re: Common Lisp for SUNS Some comments on John Foderaro's comments on "C-based" Lisps This is in response John Foderaro's comments on "C based" Lisps on the Sun 4. (IBUKI Common Lisp, a derivative of Kyoto Common Lisp, is such a "C based" lisp.) First, a general remark, comparisons with Franz Lisp are simply not valid. Professors Yuasa and Hagiya, the original designers of KCL, had the benefit of 3 decades of work on Lisp implementation and compiler development (including Franz Lisp and all the more recent work on compiler technology) on which to base their work. They knew all of this technology. In addition they are first class computer scientists and awesome hackers. They were extremely concerned with performance and they built a system which competes quite favorably with "direct" implementations. (John should consider not what he did those many years ago but rather what he would be capable of doing today.) With respect to John's specific comments. 1) The use of global registers on the Sun 4. "The Sun4 has 7 global registers. Allegro stores nil and a pointer to our global function table in one of them, and uses another for tracking asynchronous interrupts. Another is used to pass argument/result counts. C doesn't permit global register declarations so you can't take advantage of this nice feature of the Sun4 in a C-based Lisp." Allegro seem to have 4 uses for the global registers: (a) pointing to a "global function table"; (b) asynchronous interrupt "tracking"; (c) nil testing. (d) multiple value handling; (a) is not necessary. I assume that the "global function table" is a transfer vector used to call Allegro kernel functions. In IBCL and KCL calls to kernel functions are directly linked and so there is no need to call indirect through a transfer vector. (This is in fact an implicit win for the C based Lisps.) (b) is of marginal value. As I recall, The Allegro compiler inserts code to poll for interrupts in which case the register is obviously of value. The only interrupt polling in IBCL however occurs when entering critical sections. (c) is of marginal value. Not having nil in a register costs at most a couple of cycles in doing a nil test (2 immediate instructions to build the constant.) The only case in which this could possibly be significant is in an extremely tight loop but in that case the IBCL back-end optimizer (the C-compiler!) can simply reserve a register for nil and store nil once on loop entry. (d) is hard to assess because I do not know much about how Allegro handles multiple values and lambda list parsing. Conceivably this could amount to a few percent in function call intensive code. The next release of IBCL will include considerable performance enhancements for function calling. (One of the beauties of the original work at Kyoto is the modularity and extensibility of the implementation -- in particular the compiler.) In short I strongly doubt that Allegro's use of global registers gives it anything more than a marginal advantage over the C based Lisps. (2) The ability to exploit tagged arithmetic. IBCL and KCL do not currently do any open coding of generic arithmetic. This loses when generic operators are used to do fixnum arithmetic. IBCL will be making considerable improvements in this area in its next release but even so in most cases the right thing to do is to use fixnum operators to do fixnum arithmetic, and floating point operators to do floating point arithmetic, i.e., add appropriate type declarations to the code. When declarations are in place IBCL and KCL compile Lisp arithmetic to equivalent C arithmetic and from that point it is doubtful that the Allegro compiler will do better than the optimizing C-compiler. I would like to add an Amen to Jim McDonald's points about benchmarking and interpretation of benchmarks. [I saw an ad recently touting one lisp as running "23% faster" than another on the Gabriels (except it didn't call them that) without any explanation of how the benchmarks were made and how they summarized the results.] Advertized benchmarks are typically run on stand alone maxed out hardware. On real systems the small size of the C based Lisps (the total image size is about 2 megs including compiler) is likely to be just as important as how registers get used. Another area where "C-based" lisps win is in the ability to tightly integrate with "foreign" code. IBCL and KCL use the systems object format and their Lisp data structures are also C data structures. The term "foreign" in this case is essentially a misnomer. Another issue that benchmarking doesn't account for is the lead time between the availability of hardware and the availability of a Lisp. For the six months or so when IBCL was the only lisp available on the Sun 4 it might have been reasonable to compare IBCL on a Sun 4 with other Lisps on a Sun 3. This is the current situation on HP Spectrum series and the MIPS based platforms (e.g., the Silicon Graphics 4D). This will undoubtedly be the situation for the new Apollo and Motorola based RISCs in the future. In each case the companies producing direct implementations are going to be in the business of trying to duplicate all of the back end complexity of the manufacturer's compilers. With the new architectures the complexity entailed in doing decent instruction scheduling and register allocation and exploiting low level parallelism is enormous. I doubt that this duplication of effort will prove to be cost effective for most applications. Dave Posner IBUKI ibuki!dbp@labrea.stanford.edu  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 88 11:23:23 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 2 Dec 88 08:04:04 PST Return-Path: Received: from sauron.think.com by Think.COM; Fri, 2 Dec 88 10:41:22 EST Received: from OCCAM.THINK.COM by sauron.think.com; Fri, 2 Dec 88 11:02:22 EST Date: Fri, 2 Dec 88 11:02 EST From: Barry Margolin Subject: Re: commonlisp types To: Jamie.Zawinski Cc: common-lisp@sail.stanford.edu In-Reply-To: <8812020545.AA12869@Think.COM> Message-Id: <19881202160232.8.BARMAR@OCCAM.THINK.COM> Date: Fri, 2 Dec 1988 00:40-EST From: Jamie.Zawinski Can someone explain the rationale behind forcing SATISFIES to accept only function-names and not lambda expressions? I can see that the compiler could have special knowledge about such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded "to avoid scoping problems." I think this means that they didn't want to create confusion about whether the lambda expressions produced lexical closures or not. Someone might think that the following would work: (defun strange-eq (x y) (typep x '(satisfies (lambda (object) (eq object y))))) barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 2 Dec 88 01:25:02 EST Received: from SPICE.CS.CMU.EDU by SAIL.Stanford.EDU with TCP; 1 Dec 88 22:04:56 PST Date: Fri, 2 Dec 1988 00:40-EST From: Jamie.Zawinski To: common-lisp@sail.stanford.edu Subject: Re: commonlisp types ...but I believe it is the case that there is no CL way to determine if a given type is defined. I wish there was some CL way to define a complex type and insert it in the existing hierarchy. For example, I once tried to define the type LIST-OF, which would be used like (TYPEP '(1 2 3) '(LIST-OF FIXNUM)) ==> T (TYPEP '(A B 3) '(LIST-OF FIXNUM)) ==> NIL (SUBTYPEP '(LIST-OF SYMBOL) 'LIST) ==> T (SUBTYPEP '(LIST-OF FIXNUM) '(LIST-OF NUMBER)) ==> T (SUBTYPEP '(LIST-OF *) '(LIST-OF LIST)) ==> NIL NIL On the TI Explorer this was really easy. In Lucid CL, it was not possible except by bashing the definitions of TYPEP and SUBTYPEP. Can someone explain the rationale behind forcing SATISFIES to accept only function-names and not lambda expressions? I can see that the compiler could have special knowledge about such forms as (SATISFIES PLUSP), but CLtL says lambdas are excluded "to avoid scoping problems." Jamie  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 1 Dec 88 11:32:20 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 1 Dec 88 08:06:41 PST Return-Path: Received: from sauron.think.com by Think.COM; Thu, 1 Dec 88 10:48:06 EST Received: from OCCAM.THINK.COM by sauron.think.com; Thu, 1 Dec 88 11:04:43 EST Date: Thu, 1 Dec 88 11:04 EST From: Barry Margolin Subject: commonlisp types To: Don Cohen Cc: common-lisp@sail.stanford.edu In-Reply-To: <8812010255.AA17146@vaxa.isi.edu> Message-Id: <19881201160446.1.BARMAR@OCCAM.THINK.COM> Date: Wed, 30 Nov 88 18:55:38 PST From: Don Cohen There seems to be nothing in CLtL that answers the question: "is x a legal type specifier?" The description of TypeP says that the type argument may be any of the legal type specifiers except (function ...) or (values ...). I would hope that would mean that for any such "legal arguments" typep would not cause an error. I would also hope that any illegal type would cause an error. On the other hand the description of how typep handles (satisfies ...) indicates that errors might well result. Intuitively, it seems to me that if an error results from that test the typep test ought to return nil, e.g., (typep nil '(satisfies zerop)) I'd like the spec to say that typep first decides whether the type is legal, and signals an error if not. Then, for things like satisfies, it applies the predicate but catches errors, and returns nil if an error occurs. What do you experts (and lawyers) out there think? Since CLtL doesn't say that TYPEP must signal an error if the type specifier is invalid, it currently "is an error" if the type specifier is not a valid type specifer other than (FUNCTION ...) or (VALUES ...). I don't think there has been any suggestion within X3J13 to change this. In general, Common Lisp tends not to require implementations to do lots of this kind of checking; at high safety optimization levels it is informally encouraged, but not required. Actually, in this particular case, I don't think that requiring an error to be signalled would be too bad. TYPEP must already do a significant amount of work to decode the type specifier, so it probably knows when the type specifier is invalid, and signalling an error would be pretty easy. However, putting this requirement into the CL standard would be an incompatible change to the language definition, with only minor gain, and I think it is kind of late for it now (we're not very far from trying to get a draft finished). As for your suggestion about (SATISFIES ...), I personally think that is a bad idea. TYPEP shouldn't silently hide bugs in the programmer's predicate. The above example should have been written as (typep nil '(and number (satisfies zerop))) barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Nov 88 22:16:36 EST Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 30 Nov 88 18:56:05 PST Posted-Date: Wed, 30 Nov 88 18:55:38 PST Message-Id: <8812010255.AA17146@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA17146; Wed, 30 Nov 88 18:55:41 PST To: common-lisp@sail.stanford.edu Subject: commonlisp types Date: Wed, 30 Nov 88 18:55:38 PST From: Don Cohen There seems to be nothing in CLtL that answers the question: "is x a legal type specifier?" The description of TypeP says that the type argument may be any of the legal type specifiers except (function ...) or (values ...). I would hope that would mean that for any such "legal arguments" typep would not cause an error. I would also hope that any illegal type would cause an error. On the other hand the description of how typep handles (satisfies ...) indicates that errors might well result. Intuitively, it seems to me that if an error results from that test the typep test ought to return nil, e.g., (typep nil '(satisfies zerop)) I'd like the spec to say that typep first decides whether the type is legal, and signals an error if not. Then, for things like satisfies, it applies the predicate but catches errors, and returns nil if an error occurs. What do you experts (and lawyers) out there think?  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 30 Nov 88 00:19:10 EST Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 20:57:39 PST Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Tue, 29 Nov 88 20:50:28 PST Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.DIALNET.SYMBOLICS.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 297298; 29 Nov 88 23:56:09 EST Date: Tue, 29 Nov 88 23:42 EST From: Robert W. Kerns Subject: Common Lisp for SUNS To: Bill Pase , common-lisp@sail.stanford.edu In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca> Message-Id: <19881130044245.2.RWK@F.ILA.Dialnet.Symbolics.COM> Date: Tue, 29 Nov 88 11:14:29 EST From: bill@red.ipsa.dnd.ca (Bill Pase) I'm especially interested in the run time performance, since we hope to use one of these lisps as a delivery vehicle for code developed on Symbolics Computers. (It'd be real nice if the lisp benchmark data was available?) Of course if anyone has experiences with using these systems as a development environment, I'd not mind hearing it. /bill I have only subjective things to give you, but you will be astonished at the performance difference between KCL and any Symbolics machine. I've only done close-in comparisons with a Symbolics system with minimum memory, running on a large Sun-3. For realistic size problems (like compilation, for instance), KCL is pretty slow. Well, compilation isn't really a fair choice since it has to get compiled twice; once in Lisp and once in C. It is also pretty weak in the development arena. I would choose either of the other two alternatives you list. The major feature of KCL is that it is nearly free, but remember, Time is Money, too. There is also a third choice: Ibuki Common Lisp, which is an improved version of KCL. It is supposedly much more usable for development, with a lot of work done on the debugger, etc. I don't know anything about its performance. I don't know its price, but I suspect it's less than the other two. There's also a fourth choice, another version of KCL, which I don't know much about.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 17:51:52 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 14:26:57 PST Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 17:12:08 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 17:12:45 EST Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 17:11:14 EST Received: by joplin.think.com; Tue, 29 Nov 88 17:12:40 EST Date: Tue, 29 Nov 88 17:12:40 EST From: gls@Think.COM Message-Id: <8811292212.AA00825@joplin.think.com> To: Greenwald@stony-brook.scrc.symbolics.com Cc: gls@Think.COM, Greenwald@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu In-Reply-To: Michael Greenwald's message of Tue, 29 Nov 88 14:05 EST <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM> Subject: inconsistency in backquote spec? Date: Tue, 29 Nov 88 14:05 EST From: Michael Greenwald Date: Tue, 29 Nov 88 12:35:36 EST From: gls@Think.COM ... You raise some good points here. At first I was certain that the book was not consistent, but now I have the following language lawyer's argument: The spec for APPEND says that all arguments but the last must be lists. The comment about the last argument makes it clear that the others are meant to be proper lists; see also the middle paragraph of page 27. Therefore dotted lists are not allowed as values for D. I thought a (recent?) CL Cleanup specified that if arguments (all but the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR was to be ignored. In which case, the examples on 351 are incorrect. Because you sent the mail out to common-lisp@sail and not to any of the X3J13 mailing lists, I assumed that you were asking a question about the language as defined solely by the book. In other words, I assume that the audience for the common-lisp mailing list has not necessarily followed all of the X3J13 work. It is true that eventual adoption of this cleanup item would invalidate the examples. --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 17:23:17 EST Received: from ucbarpa.Berkeley.EDU by SAIL.Stanford.EDU with TCP; 29 Nov 88 13:53:02 PST Received: by ucbarpa.Berkeley.EDU (5.61/1.29) id AA24518; Tue, 29 Nov 88 13:52:04 PST Received: from frisky by franz (3.2/3.14) id AA24713; Tue, 29 Nov 88 13:43:03 PST Received: by frisky (3.2/3.14) id AA02600; Tue, 29 Nov 88 13:40:54 PST From: franz!frisky!jkf@ucbarpa.Berkeley.EDU (John Foderaro) Return-Path: Message-Id: <8811292140.AA02600@frisky> To: franz!ucbarpa!red.ipsa.dnd.ca!bill (Bill Pase) Cc: franz!sail.stanford.edu!common-lisp Subject: Re: Common Lisp for SUNS In-Reply-To: Your message of Tue, 29 Nov 88 11:14:29 EST. <8811291614.AA01479@red.ipsa.dnd.ca> Date: Tue, 29 Nov 88 13:40:53 PST Regarding benchmarking Lisps. 1. Declarations are important for speed, but you'll find that some Lisps will require more specific declarations than others. For example Sun's Lisp only supports one floating point type so declaring something to be a 'float' is sufficient for the compiler to open code the operation. Allegro supports two types of floats so you must declare either 'single-float' or 'double-float.' 2. Different systems do different amounts of optimizations based on the settings of the optimization parameters speed, safety and size. Probably the only comparable values are for speed=3, safety=0, size=0 where each system does maximum optimization. While benchmarks run at this value are interesting you probably aren't going to do development with these settings since you aren't going to get good diagnostics. Regarding the Lisp on the Sun4. Allegro is highly optimized for the Sun4 but you have to add some declarations and specify that speed is important. The comment was made that a C based Lisp on the Sun4 would be very fast because of sun's optimizing C compiler. While it is true that by using C you can take advantage of that compiler, it is also true that the use of C constrains your whole system design so you can't use the machine optimally. I say this from many years experience programming in C parts of the kernel of Franz Lisp. To cite two examples for the Sun4: One of the nicest features of the sun4 (sparc) architecture is the support the the Lisp fixnum data type (there are 'tagged' versions of the add, subtract and compare instructions). This allows the compiler to open code +,-,<,<=.. and so on and if the operands happen to be fixnums (they very often are) then the operation and fixnum tag check can go on in parallel. This makes for fast computation in the typical case and it is completely safe (if the tags aren't fixnum you find out about it and perform the appropriate operation for the actual data types). A C based lisp can't make use of these tagged instructions. The Sun4 has 7 global registers. Allegro stores nil and a pointer to our global function table in one of them, and uses another for tracking asychronous interrupts. Another is used to pass argument/result counts. C doesn't permit global register declarations so you can't take advantage of this nice feature of the Sun4 in a C-based Lisp. [The use of machine registers to hold certain values was so important in Franz Lisp that for certain regular architectures (e.g. vax) an incredible hack was written by Keith Sklower to modify the assembler language coming out of the C compiler to change certain memory references to register references and to fix the register save masks.] -- John Foderaro Franz Inc. jkf%franz.uucp@berkeley.edu  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 14:56:53 EST Received: from SAPSUCKER.SCRC.Symbolics.COM ([128.81.41.223]) by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:36:04 PST Received: from NOEL-COWARD.SCRC.Symbolics.COM by SAPSUCKER.SCRC.Symbolics.COM via INTERNET with SMTP id 262367; 29 Nov 88 14:02:36 EST Date: Tue, 29 Nov 88 14:05 EST From: Michael Greenwald Subject: inconsistency in backquote spec? To: gls@Think.COM, Greenwald@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <8811291735.AA00711@joplin.think.com> Message-ID: <19881129190543.1.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM> Date: Tue, 29 Nov 88 12:35:36 EST From: gls@Think.COM Date: Mon, 28 Nov 88 20:44 EST From: Michael Greenwald (setq d '(a . b)) '`(,@d) => `(a . b) or `(a)? If you read CLtL, pg 350. it says that it's equivalent to `(,@d . nil) which is (append [,@d] 'nil) (append d 'nil) which suggests the correct value is `(a). ... Are dotted lists not allowed as values of D? Is the spec on pg 350 correct, and the examples on pg. 351 incorrect? I tend to believe the latter. In which case, all of the readers I tried are incorrect. I'm not going to change the Genera reader, though, until I hear from this list, in case my brain is just wedged. Can someone either deconfuse or support me? You raise some good points here. At first I was certain that the book was not consistent, but now I have the following language lawyer's argument: The spec for APPEND says that all arguments but the last must be lists. The comment about the last argument makes it clear that the others are meant to be proper lists; see also the middle paragraph of page 27. Therefore dotted lists are not allowed as values for D. I thought a (recent?) CL Cleanup specified that if arguments (all but the last) to APPEND (or NCONC) were dotted lists, the non-nil final CDR was to be ignored. In which case, the examples on 351 are incorrect. Or, you could say that the list following a ,@ cannot be dotted. Either way, I think, requires a minor clarification in the CL spec. The examples on page 351 are also correct. Once you are given that D may not be dotted, and given that the result of a backquoted expression may or may not make copies, then the examples shown are correct optimizations. --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 14:46:08 EST Received: from tut.cis.ohio-state.edu by SAIL.Stanford.EDU with TCP; 29 Nov 88 11:27:05 PST Received: by tut.cis.ohio-state.edu (5.59/2.881128) id AA25824; Tue, 29 Nov 88 14:12:36 EST Date: Tue, 29 Nov 88 14:12:36 EST From: Arun Welch Message-Id: <8811291912.AA25824@tut.cis.ohio-state.edu> To: barmar@think.com Cc: common-lisp@sail.stanford.edu Subject: Re: Common Lisp for SUNS > >Kyoto CL is not generally considered a high-performance Lisp. Its major >feature is its portability, since it is written mostly in C and its >compiler uses C as the intermediate language. It is also well-known for >being very faithful to CLtL, implementing all and only what the book >says. We're in the process of coming up with a decision on what lisp to get for the University, and have been looking at Ibuki, Franz, and Envos (and, as soon as Sun sends us the tape, Sun/ Lucid). Part of this has been benchmarking them on Sun-3's and Sun-4's, and we've noticed that in some benchmarks on the -4 Ibuki comes out ahead of the others. We were kind of amazed by this, until we realised that Ibuki uses the native C compiler, which is optimising for the SPARC architecture on the -4, while none of the others were. This wasn't an across-the-board speedup, just for some of the things we tried. I'd pretty much agree with your other assessment of Kyoto CL, modulo the fact that Ibuki has extended it somewhat (folding in the new error system, for example). ...arun ---------------------------------------------------------------------------- Arun Welch Lisp Systems Programmer, Lab for AI Research, Ohio State University welch@tut.cis.ohio-state.edu  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 14:10:10 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:50:46 PST Received: from NOEL-COWARD.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 499350; 29 Nov 88 13:50:23 EST Date: Tue, 29 Nov 88 13:55 EST From: Michael Greenwald Subject: inconsistency in backquote spec? To: jonl@lucid.com, Greenwald@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <8811290810.AA00624@bhopal> Message-ID: <19881129185543.0.GREENWALD@NOEL-COWARD.SCRC.Symbolics.COM> Date: Tue, 29 Nov 88 00:10:53 PST From: Jon L White re: However, the example at the bottom of page 350 suggest alternate "legitimate interpretations" continued on the top of pg 351. All of them except the first, consider (APPEND .... D NIL) to be equivalent to (APPEND ... D), which isn't true if D can be a dotted list. [This may be a question about "standard lists" more than about backquote.] I remember some sleeping dogs about APPEND -- all arguments except the last are required to be "lists". Since APPEND has to copy the next to last argument, it must cdr down to the last cell of the list; thus it should complain about non-standard lists. [The permission to use non-standard lists is primarily when the operation of interest will not cdr down to the last cell, and hence it would be a moot question.] Long long ago, Lucid made the decision to make non-standard lists acceptable just about everwhere that "lists" are. Thus in Lucid Common Lisp: (APPEND '(A . B) NIL) ==> (A) (APPEND NIL '(A . B)) ==> (A . B) I agree with this (I think there's a CL cleanup that specifies this behavior for APPEND and NCONC), and therefore the Lucid backquote implementation is inconsistent with the definition of APPEND. (setq d '(a . b)) `(,@d) `(,@d . nil) (append [,@d] 'nil) (append d 'nil) (append '(a . b) 'nil) should be (a), as in your example above. However, it was (a . b) on the version I tried - I didn't try the APPEND case itself, so maybe in a later version both were made consistent. I can't say that I am fully happy with this; but it's very low on my list of worries today. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 13:56:07 EST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:35:37 PST Received: from Burger.ms by ArpaGateway.ms ; 29 NOV 88 10:27:42 PST Sender: "Larry_Masinter.PARC"@Xerox.COM Date: 29 Nov 88 10:23:29 PST (Tuesday) Subject: Re: inconsistency in backquote spec? From: "Larry_Masinter.PARC"@Xerox.COM To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp@sail.stanford.EDU In-Reply-to: Greenwald%STONY-BROOK.SCRC.Symbolics:COM:Xerox's message of 28 Nov 88 18:12 Message-ID: <881129-102742-5383@Xerox> There are two relevant cleanup proposals, one of which passed, and the other still pending. The first, called APPEND-DOTTED, clarifies the behavior of APPEND given dotted lists. The second, which is really not firm at all, is called BACKQUOTE-UNDERSPECIFIED, and it will attempt to specify more precisely the behavior of backquote in terms of what parts of the expansion get newly consed, etc. Status: PASSED Issue: APPEND-DOTTED References: APPEND (p268) Category: CHANGE/CLARIFICATION Edit history: 27-Jul-87, Version 1 by Pitman 29-Oct-87, Version 2 by Pitman (loose ends) 14-Nov-87, Version 3 by Masinter 23-Nov-87, Version 4 by Masinter 14-Jan-88, Version 5 by Masinter Problem Description: The description of APPEND on p268 is not adequately clear on the issue of what happens if an argument to APPEND is a dotted list. The only case explicitly mentioned is the last argument, viz: "The last argument [to APPEND] actually need not be a list but may be any LISP object, which becomes the tail end of the constructed list. For example, (append '(a b c) 'd) => (a b c . d)." While this specifies the behavior of APPEND when the last argument is not a list, the behavior when any of the other arguments are not lists is not specified. Proposal (APPEND-DOTTED:REPLACE): Define that the cdr of the last cons in any but the last argument given to APPEND or NCONC is discarded (whether NIL or not) when preparing the list to be returned. In the degenerate case where there is no last cons (i.e., the argument is NIL) in any but the last list argument, clarify that the entire argument is effectively ignored. Point out that in this situation, if the last argument is a non-list, the result of APPEND or NCONC can be a non-list. Remove any text which suggests that (APPEND x '()) and (COPY-LIST x) are the same, since these two might legitimately differ in situations involving dotted lists. As such, deciding which to use is not just a stylistic issue. Examples: (APPEND '(A B C . D) '()) => (A B C) ;Proposed (NCONC (LIST* 'A 'B 'C 'D) '()) => (A B C) ;Proposed Note that (COPY-LIST '(A B C . D)) would still return (A B C . D). (APPEND '(A B . C) '() 3) => (A B . 3) ;Proposed (NCONC (LIST* 'A 'B 'C) '() 3) => (A B . 3) ;Proposed (APPEND '() 17) => 17 ;Proposed (NCONC (LIST) 17) => 17 ;Proposed Rationale: This function is used a lot and its behavior should be well-defined across implementations. This proposal upholds the apparent status quo in a number of implementations. Current Practice: Symbolics Lisp, Vaxlisp, and Lucid Lisp appear to implement the proposed interpretation (at least in the interpreter). Franz's Allegro Common Lisp conforms to the proposed behavior except in the case of (NCONC (LIST) 17) => 17, where it returns NIL instead of 17. Kyoto Common Lisp signal an error when using APPEND or NCONC on a dotted list. Xerox Common Lisp signals an error on APPEND and implements the proposed interpretation on NCONC. Cost to implementors: Technically, the change should be relatively small for those implementations which don't already implement it. However, implementations which have microcoded APPEND or NCONC incompatibly may find the small change somewhat painful. Some implementations may have optimized their APPEND or NCONC to expect only NIL when SAFETY is 0. In this case, depending on implementation details, requiring an ATOM check rather than a NULL check may slow things down. Cost to users: This change is upward compatible. Benefits: Since non-lists are allowed as a last argument and since APPEND and NCONC can therefore produce dotted lists, some readers may have (incorrectly) assumed that APPEND and NCONC can reliably deal in general with dotted lists, something that doesn't appear to be guaranteed by a strict reading. The proposed extension would happen to legitimize such assumptions. Aesthetics: Whether or not users will think this improves the aesthetics of the language will depend largely on how they view the relation between lists and dotted lists. Those who view dotted lists as a special kind of list may feel differently than those who view lists as a special kind of dotted list. Discussion: The cleanup committee supports this proposal.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 13:28:51 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 10:09:03 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01681g; Tue, 29 Nov 88 10:06:59 PST Received: by bhopal id AA01309g; Tue, 29 Nov 88 10:05:50 PST Date: Tue, 29 Nov 88 10:05:50 PST From: Jim McDonald Message-Id: <8811291805.AA01309@bhopal> To: bill@red.ipsa.dnd.ca In-Reply-To: Bill Pase's message of Tue, 29 Nov 88 11:14:29 EST <8811291614.AA01479@red.ipsa.dnd.ca> Subject: Common Lisp for SUNS Cc: common-lisp@sail.stanford.edu I'm not the right person to send you benchmark data on Lucid Common Lisp, but I thought I should mention that Sun Common Lisp is Lucid Common Lisp. (Lucid makes it, Sun sells it.) Also, I can give some general advice about benchmarks: (1) Be sure to note the releases being compared. For example, LCL Version 3.0 is significantly different from LCL Version 2.1. We added a second compiler, an ephemeral garbage collector, multi-tasking, better inline floating point code, new interrupts, new I/O, etc., etc. (2) Be sure that the person who produced the benchmark values understands the benchmarks and the lisp being tested. Proper use of declarations and compiler settings can sometimes produce order-of-magnitude differences. Also, for example, the use of a feature such as ephemeral garbage collection may reflect a decision to accept a somewhat increased running time in order to avoid detectable pauses for GC. Turning EGC off may result in different (usually faster) benchmark values, and might or might not be appropriate for various applications. You need to understand how you're going to use the lisp to know what settings are appropriate. (3) Ask for the *precise* techniques used to obtain the benchmarks, including processor speed, memory size, load on the machine, etc. I know that some of the people at Lucid have produced benchmark figures using what we call the "low-mode" -- we run each benchmark about 20 times or more, then use some statistics to produce a number one could expect to be the low value obtained in a typical set of about 3 runs. (We didn't want to just scrounge for the lowest value, since that's not always reproducible, yet did want to give a fair indication of the performance possible.) I'm pretty sure the techniques used are distributed with the benchmark numbers. (4) If performance is critical, explain this to the vendor. For example, Lucid is now productizing tools to reorganize your code based on an analysis of its dynamic performance, since code and data locality can have order-of-magnitude affects on real-life applications. Remember that you are going to be running applications day-to-day, and not just benchmarks. Support in this area can be as crucial as the underlying speed of the lisp! Happy hunting, jlm  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 12:54:46 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:36:59 PST Received: from fafnir.think.com by Think.COM; Tue, 29 Nov 88 12:34:44 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Tue, 29 Nov 88 12:35:41 EST Received: from joplin.think.com by verdi.think.com; Tue, 29 Nov 88 12:34:10 EST Received: by joplin.think.com; Tue, 29 Nov 88 12:35:36 EST Date: Tue, 29 Nov 88 12:35:36 EST From: gls@Think.COM Message-Id: <8811291735.AA00711@joplin.think.com> To: Greenwald@stony-brook.scrc.symbolics.com Cc: common-lisp@sail.stanford.edu In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM> Subject: inconsistency in backquote spec? Date: Mon, 28 Nov 88 20:44 EST From: Michael Greenwald (setq d '(a . b)) '`(,@d) => `(a . b) or `(a)? If you read CLtL, pg 350. it says that it's equivalent to `(,@d . nil) which is (append [,@d] 'nil) (append d 'nil) which suggests the correct value is `(a). ... Are dotted lists not allowed as values of D? Is the spec on pg 350 correct, and the examples on pg. 351 incorrect? I tend to believe the latter. In which case, all of the readers I tried are incorrect. I'm not going to change the Genera reader, though, until I hear from this list, in case my brain is just wedged. Can someone either deconfuse or support me? You raise some good points here. At first I was certain that the book was not consistent, but now I have the following language lawyer's argument: The spec for APPEND says that all arguments but the last must be lists. The comment about the last argument makes it clear that the others are meant to be proper lists; see also the middle paragraph of page 27. Therefore dotted lists are not allowed as values for D. The examples on page 351 are also correct. Once you are given that D may not be dotted, and given that the result of a backquoted expression may or may not make copies, then the examples shown are correct optimizations. --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 12:23:56 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 29 Nov 88 09:04:27 PST Return-Path: Received: from sauron.think.com by Think.COM; Tue, 29 Nov 88 12:02:03 EST Received: from OCCAM.THINK.COM by sauron.think.com; Tue, 29 Nov 88 12:02:57 EST Date: Tue, 29 Nov 88 12:03 EST From: Barry Margolin Subject: Common Lisp for SUNS To: Bill Pase Cc: common-lisp@sail.stanford.edu In-Reply-To: <8811291614.AA01479@red.ipsa.dnd.ca> Message-Id: <19881129170307.7.BARMAR@OCCAM.THINK.COM> Date: Tue, 29 Nov 88 11:14:29 EST From: bill@red.ipsa.dnd.ca (Bill Pase) Can anyone tell me about their experiences with Common Lisp systems for Sun Computers. I know of four implementations, Kyoto Common Lisp, Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp. Sun Common Lisp currently is Lucid Common Lisp. There were rumors last year that they would be switching to Franz (who makes Allegro CL), but this doesn't appear to have happened. Kyoto CL is not generally considered a high-performance Lisp. Its major feature is its portability, since it is written mostly in C and its compiler uses C as the intermediate language. It is also well-known for being very faithful to CLtL, implementing all and only what the book says. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 11:35:01 EST Received: from red.ipsa.dnd.ca by SAIL.Stanford.EDU with TCP; 29 Nov 88 08:13:45 PST Received: by red.ipsa.dnd.ca; (5.54/4.7) id AA01479; Tue, 29 Nov 88 11:14:29 EST Date: Tue, 29 Nov 88 11:14:29 EST From: bill@red.ipsa.dnd.ca (Bill Pase) Message-Id: <8811291614.AA01479@red.ipsa.dnd.ca> To: common-lisp@sail.stanford.edu Subject: Common Lisp for SUNS Can anyone tell me about their experiences with Common Lisp systems for Sun Computers. I know of four implementations, Kyoto Common Lisp, Lucid Common Lisp, Sun Common Lisp, and Allegro Common Lisp. I'm especially interested in the run time performance, since we hope to use one of these lisps as a delivery vehicle for code developed on Symbolics Computers. (It'd be real nice if the lisp benchmark data was available?) Of course if anyone has experiences with using these systems as a development environment, I'd not mind hearing it. /bill  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 29 Nov 88 03:33:32 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 29 Nov 88 00:14:07 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA01440g; Tue, 29 Nov 88 00:12:00 PST Received: by bhopal id AA00624g; Tue, 29 Nov 88 00:10:53 PST Date: Tue, 29 Nov 88 00:10:53 PST From: Jon L White Message-Id: <8811290810.AA00624@bhopal> To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM Cc: common-lisp@sail.stanford.edu In-Reply-To: Michael Greenwald's message of Mon, 28 Nov 88 20:44 EST <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM> Subject: inconsistency in backquote spec? re: However, the example at the bottom of page 350 suggest alternate "legitimate interpretations" continued on the top of pg 351. All of them except the first, consider (APPEND .... D NIL) to be equivalent to (APPEND ... D), which isn't true if D can be a dotted list. [This may be a question about "standard lists" more than about backquote.] I remember some sleeping dogs about APPEND -- all arguments except the last are required to be "lists". Since APPEND has to copy the next to last argument, it must cdr down to the last cell of the list; thus it should complain about non-standard lists. [The permission to use non-standard lists is primarily when the operation of interest will not cdr down to the last cell, and hence it would be a moot question.] Long long ago, Lucid made the decision to make non-standard lists acceptable just about everwhere that "lists" are. Thus in Lucid Common Lisp: (APPEND '(A . B) NIL) ==> (A) (APPEND NIL '(A . B)) ==> (A . B) I can't say that I am fully happy with this; but it's very low on my list of worries today. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 28 Nov 88 21:05:02 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 28 Nov 88 17:45:07 PST Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 498891; Mon 28-Nov-88 20:45:07 EST Date: Mon, 28 Nov 88 20:44 EST From: Michael Greenwald Subject: inconsistency in backquote spec? To: common-lisp@sail.stanford.edu Message-ID: <19881129014452.7.GREENWALD@SWALLOW.SCRC.Symbolics.COM> (setq d '(a . b)) '`(,@d) => `(a . b) or `(a)? If you read CLtL, pg 350. it says that it's equivalent to `(,@d . nil) which is (append [,@d] 'nil) (append d 'nil) which suggests the correct value is `(a). If you look at most implementations, and at the examples on pg 351, then you'd think it should be `(a . b) However, the example at the bottom of page 350 suggest alternate "legitimate interpretations" continued on the top of pg 351. All of them except the first, consider (APPEND .... D NIL) to be equivalent to (APPEND ... D), which isn't true if D can be a dotted list. I tried Ibuki, Franz, Lucid, and Genera. In all of them evaluating '`(,@'(a . b)) => `(a . b). In Ibuki and Lucid '`(,@'(a . b) ,@nil) => '([bq-]append '(a . b) nil) while in Genera and Franz '`(,@'(a . b) ,@nil) => `(a . b) Are dotted lists not allowed as values of D? Is the spec on pg 350 correct, and the examples on pg. 351 incorrect? I tend to believe the latter. In which case, all of the readers I tried are incorrect. I'm not going to change the Genera reader, though, until I hear from this list, in case my brain is just wedged. Can someone either deconfuse or support me?  Received: from life.ai.mit.edu (TCP 20015020120) by AI.AI.MIT.EDU 18 Nov 88 16:44:36 EST Received: from SAIL.Stanford.EDU by life.ai.mit.edu; Fri, 18 Nov 88 08:15:14 EST Message-Id: <8811181315.AA10165@life.ai.mit.edu> Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 18 Nov 88 02:33:15 PST Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP id aa01665; 15 Nov 88 13:02 GMT Received: from xenakis by mordell.maths.bath.AC.UK id aa12898; 15 Nov 88 11:41 GMT To: Greenwald@scrc-stony-brook.arpa Cc: jonl%lucid.com@nss.cs.ucl.ac.uk, Greenwald@scrc-stony-brook.arpa, KMP@scrc-stony-brook.arpa, donc@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: Michael Greenwald's message of Mon, 14 Nov 88 11:40 EST <19881114164032.1.GREENWALD@SWALLOW.SCRC.Symbolics.COM> Subject: backquote Date: Tue, 15 Nov 88 11:40:26 GMT From: jpff%maths.bath.ac.uk@nss.cs.ucl.ac.uk Sender: jpff%maths.bath.ac.uk@nss.cs.ucl.ac.uk OK, I have tried to read the backquote material. What is the correct meaning of ``(,@,@x) please? ==John  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 18 Nov 88 15:56:04 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 18 Nov 88 10:41:07 PST Received: from fafnir.think.com by Think.COM; Fri, 18 Nov 88 13:12:41 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Fri, 18 Nov 88 13:36:17 EST Received: from joplin.think.com by verdi.think.com; Fri, 18 Nov 88 13:36:16 EST Received: by joplin.think.com; Fri, 18 Nov 88 13:36:12 EST Date: Fri, 18 Nov 88 13:36:12 EST From: gls@Think.COM Message-Id: <8811181836.AA01536@joplin.think.com> To: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK Cc: Greenwald@scrc-stony-brook.arpa, jonl%lucid.com@NSS.Cs.Ucl.AC.UK, Greenwald@scrc-stony-brook.arpa, KMP@scrc-stony-brook.arpa, donc@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK's message of Tue, 15 Nov 88 11:40:26 GMT <8811181010.AA11573@Think.COM> Subject: backquote Date: Tue, 15 Nov 88 11:40:26 GMT From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK OK, I have tried to read the backquote material. What is the correct meaning of ``(,@,@x) please? ==John Here is a concise, if not precise, description: `(,@q) means "I evaluate to a list with the list named q spliced in" ``(,@,@x) means "I evaluate to an expression that, when evaluated, will make a list with the values of lots of list spliced in, where x is a list of forms that will evaluate to those lists" and, if you can stomach it, ```(,@,@,@x) means "I evaluate to an expression that, when evaluated, produces an expression that, when evaluated, will make a list with the values of lots of list spliced in, where x is a list of forms, each of which will evaluate to a form that when evaluated will produce a list for splicing" Got that? --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Nov 88 18:17:45 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Nov 88 15:00:23 PST Received: from fafnir.think.com by Think.COM; Wed, 16 Nov 88 17:35:05 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Wed, 16 Nov 88 17:56:39 EST Received: from joplin.think.com by verdi.think.com; Wed, 16 Nov 88 17:56:38 EST Received: by joplin.think.com; Wed, 16 Nov 88 17:56:34 EST Date: Wed, 16 Nov 88 17:56:34 EST From: gls@Think.COM Message-Id: <8811162256.AA00511@joplin.think.com> To: donc@vaxa.isi.edu Cc: gls@Think.COM, greenwald@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu In-Reply-To: Don Cohen's message of Wed, 16 Nov 88 11:54:30 PST <8811161954.AA03714@vaxa.isi.edu> Subject: nested backquotes Posted-Date: Wed, 16 Nov 88 11:54:30 PST Date: Wed, 16 Nov 88 11:54:30 PST From: Don Cohen I agree that my model does not handle this case. I had a hard time seeing how your model does. The Greenwald explanation gives me a hint of how to interpret CLtL. I think what I was missing was the idea that [,,x] would be interpreted by treating the inner comma as part of the form in the outer comma, e.g., [(comma (comma x))] => (list (comma x)). Just to test my new interpretation, does this look right? (setq x '(y z)) ``(,@,@x) => `(append [,@,@x] 'nil) => `(append ,@x 'nil) => (append [append] [,@x] ['nil] nil) => (append (list 'append) x (list ''nil) nil) which evaluates to (APPEND Y Z 'NIL) Right!  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Nov 88 16:00:15 EST Received: from CASABLANCA.BBN.COM by SAIL.Stanford.EDU with TCP; 16 Nov 88 12:41:45 PST Date: Wed, 16 Nov 88 15:30:57 EST From: Art Mellor To: common-lisp@sail.stanford.edu Subject: Remove amellor@bbn.com please see subject  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Nov 88 15:21:10 EST Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 16 Nov 88 11:58:11 PST Posted-Date: Wed, 16 Nov 88 11:54:30 PST Message-Id: <8811161954.AA03714@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA03714; Wed, 16 Nov 88 11:54:49 PST To: gls@think.com Cc: greenwald@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu Subject: Re: nested backquotes In-Reply-To: Your message of Wed, 16 Nov 88 13:00:23 -0500. <8811161800.AA00323@joplin.think.com> Date: Wed, 16 Nov 88 11:54:30 PST From: Don Cohen I agree that my model does not handle this case. I had a hard time seeing how your model does. The Greenwald explanation gives me a hint of how to interpret CLtL. I think what I was missing was the idea that [,,x] would be interpreted by treating the inner comma as part of the form in the outer comma, e.g., [(comma (comma x))] => (list (comma x)). Just to test my new interpretation, does this look right? (setq x '(y z)) ``(,@,@x) => `(append [,@,@x] 'nil) => `(append ,@x 'nil) => (append [append] [,@x] ['nil] nil) => (append (list 'append) x (list ''nil) nil) which evaluates to (APPEND Y Z 'NIL)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 16 Nov 88 13:25:33 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Nov 88 10:03:27 PST Received: from fafnir.think.com by Think.COM; Wed, 16 Nov 88 12:38:56 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Wed, 16 Nov 88 13:00:27 EST Received: from joplin.think.com by verdi.think.com; Wed, 16 Nov 88 13:00:26 EST Received: by joplin.think.com; Wed, 16 Nov 88 13:00:23 EST Date: Wed, 16 Nov 88 13:00:23 EST From: gls@Think.COM Message-Id: <8811161800.AA00323@joplin.think.com> To: donc@vaxa.isi.edu Cc: gls@Think.COM, greenwald@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu In-Reply-To: Don Cohen's message of Mon, 14 Nov 88 15:29:34 PST <8811142330.AA12027@vaxa.isi.edu> Subject: nested backquotes Posted-Date: Mon, 14 Nov 88 15:29:34 PST Date: Mon, 14 Nov 88 15:29:34 PST From: Don Cohen Now there's a good point. What does that mean anyhow? Please try to justify your answer. Look, I've already provided a model. You're trying to produce a new model. The task is to prove that they are equivalent; in other words, that for any backquoted expression the two models provide equivalent interpretations. (Alternatively, where the two models produce inequivalent results, you need to argue that the first model is bogus. That would be a really interesting result!) Now, for some backquoted expressions your model produces intermediate results in which COMMA has more than one argument form. So you need either to provide an interpretation in your model for such intermediate results (i.e., new productions), or to argue that backquoted expressions that produce such intermediate results are not meaningful. --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 88 21:39:13 EST Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 14 Nov 88 18:17:11 PST Posted-Date: Mon, 14 Nov 88 15:29:34 PST Message-Id: <8811142330.AA12027@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA12027; Mon, 14 Nov 88 15:30:27 PST To: gls@think.com Cc: greenwald@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu Subject: Re: nested backquotes In-Reply-To: Your message of Mon, 14 Nov 88 16:46:15 -0500. <8811142146.AA29789@joplin.think.com> Date: Mon, 14 Nov 88 15:29:34 PST From: Don Cohen Now there's a good point. What does that mean anyhow? Please try to justify your answer.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 88 18:00:29 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 14 Nov 88 14:37:38 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA00533g; Mon, 14 Nov 88 14:35:51 PST Received: by bhopal id AA21716g; Mon, 14 Nov 88 14:34:27 PST Date: Mon, 14 Nov 88 14:34:27 PST From: Jon L White Message-Id: <8811142234.AA21716@bhopal> To: donc@vaxa.isi.edu Cc: greenwald@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu In-Reply-To: Don Cohen's message of Mon, 14 Nov 88 09:11:39 PST <8811141711.AA04256@vaxa.isi.edu> Subject: nested backquotes The problem with "explanations" of backquote is that they tend to be much longer than the "production rules" on CLtL p.349-50. Of course, the problem with CLtL here is opacity. The only rule I ever remember, and found quite useful, is: "When in doubt, Hack it out." In short, after implementing the rules of CLtL rigorously, then I just try reading (and sometimes macroexpanding) several variants of the form I'm trying to build up. Apart from ultimately matching the depth of nesting for commas and backquotes, I just try a lot of variations of ",," ",'," ",,@" etc. You'd be surprised how useful the "hack it out" rule is! especially in leanring when ",'," must be used instead of ",,". One program I was writing once wound up 6 levels deep; the "hack it out" rule wasn't very helpful here, because the expression was too large. Ultimately, I wound up finding a "break point", and pulled out some of the code into a separate function, much as you originally did in your first example with BUILD-LET-LIST. At that point it was 4 levels and 2 levels -- much more managable. -- JonL --  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 88 17:10:45 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88 13:50:22 PST Received: from fafnir.think.com by Think.COM; Mon, 14 Nov 88 16:27:03 EST Return-Path: Received: from verdi.think.com by fafnir.think.com; Mon, 14 Nov 88 16:46:19 EST Received: from joplin.think.com by verdi.think.com; Mon, 14 Nov 88 16:46:18 EST Received: by joplin.think.com; Mon, 14 Nov 88 16:46:15 EST Date: Mon, 14 Nov 88 16:46:15 EST From: gls@Think.COM Message-Id: <8811142146.AA29789@joplin.think.com> To: donc@vaxa.isi.edu Cc: greenwald@stony-brook.scrc.symbolics.com, common-lisp@sail.stanford.edu In-Reply-To: Don Cohen's message of Mon, 14 Nov 88 09:11:39 PST <8811141711.AA04256@vaxa.isi.edu> Subject: nested backquotes Posted-Date: Mon, 14 Nov 88 09:11:39 PST Date: Mon, 14 Nov 88 09:11:39 PST From: Don Cohen I think I understand your description (I think you left out a quote or two in the last element). Furthermore, I strongly suspect (but have not yet proven) that it is equivalent to mine. If so, my explanation seems easier to understand. The only problem was that you evidently did not understand what "matching" meant. It was very simple and did NOT require expanding the inner backquotes. Let me rephrase the model and see if you agree that it gives the same results as yours. Pretend that comma (comma@) reads like quote - ,x = (COMMA x) except that an expression may not be in the scope of more commas than backquotes. Similarly, suppose that backquote reads as the symbol BACKQUOTE consed onto the next read. So ``(a ,s ,',d ,,f `(,g)) reads as (BACKQUOTE BACKQUOTE a (COMMA s) (COMMA (QUOTE (COMMA d))) (COMMA (COMMA f)) (BACKQUOTE ((COMMA g)))) Now in order to evaluate that expression we find all forms that are in the scope of as many COMMAs as BACKQUOTEs. We discard the leading BACKQUOTE and replace such expressions (along with the matching COMMAs) with their values. In this case, the d and f are in the scope of 2 of each. The result is (BACKQUOTE a (COMMA s) (COMMA (QUOTE 4)) (COMMA 7) (BACKQUOTE ((COMMA g)))) Evaluating this would similarly give something like (a 3 4 7 (BACKQUOTE ((COMMA g)))) If you don't believe this model is equivalent please send me a counterexample. (The only thing I can see won't work is if something EVALUATES to a list containing the symbols BACKQUOTE or COMMA, and I think we can pretend that's impossible, even though it's precisely what I really WANTED to do!) I believe that this model can be made to work, but you need additional rules to explain what happens when ``(a ,,@f) expands to (BACKQUOTE BACKQUOTE a (COMMA (COMMA@ f))). At the very least you must allow for COMMA having more than one subform. --Guy  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 88 13:48:17 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Nov 88 10:27:20 PST Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 492023; Mon 14-Nov-88 13:27:23 EST Date: Mon, 14 Nov 88 13:27 EST From: Michael Greenwald Subject: nested backquotes To: donc@vaxa.isi.edu, greenwald@STONY-BROOK.SCRC.Symbolics.COM cc: common-lisp@sail.stanford.edu In-Reply-To: <8811141711.AA04256@vaxa.isi.edu> Message-ID: <19881114182707.6.GREENWALD@SWALLOW.SCRC.Symbolics.COM> Date: Mon, 14 Nov 88 09:11:39 PST From: Don Cohen I think I understand your description (I think you left out a quote or two in the last element). Furthermore, I strongly suspect (but have not yet proven) that it is equivalent to mine. If so, my explanation seems easier to understand. You said: "I don't see how to interpret CLtL to mean this (innermost backquote expanded first??)" I was just explaining the behavior of readers (that you determined "experimentally") did conform to CLtL. I thought you decided that CLtL did not define the case of nested backquotes unambiguously. I was just pointing out that CLtL's rules defining the interpretation of nested backquote cases *are* well-defined. I don't claim that the rules are an example of pedagogic clarity, or that your explication isn't easier to understand, I was just showing you how CLtL's rules work. The rule (in concise form) is: Expand the innermost backquote first, always using the outermost comma. The rule itself is simple. In more complicated situations the productions are ugly, taking many steps, and your model probably describes the behavior more clearly. I don't know. I haven't tried to prove that your model is equivalent to CLtL's rule, but intuitively they seem equivalent. If you understand CLtL's rule now, then you can use your model with more confidence, since your original problem seemed to be that you didn't know how to derive the behavior of readers from the specification in CLtL. If you can prove that your model is equivalent, and if it is accepted that your model is a clearer and cleaner explanation, then your model should probably be included in a future backquote specification as a useful guideline. The only problem was that you evidently did not understand what "matching" meant. It was very simple and did NOT require expanding the inner backquotes. Let me rephrase the model and see if you agree that it gives the same results as yours. Pretend that comma (comma@) reads like quote - ,x = (COMMA x) except that an expression may not be in the scope of more commas than backquotes. Similarly, suppose that backquote reads as the symbol BACKQUOTE consed onto the next read. So ``(a ,s ,',d ,,f `(,g)) reads as (BACKQUOTE BACKQUOTE a (COMMA s) (COMMA (QUOTE (COMMA d))) (COMMA (COMMA f)) (BACKQUOTE ((COMMA g)))) Now in order to evaluate that expression we find all forms that are in the scope of as many COMMAs as BACKQUOTEs. We discard the leading BACKQUOTE and replace such expressions (along with the matching COMMAs) with their values. In this case, the d and f are in the scope of 2 of each. The result is (BACKQUOTE a (COMMA s) (COMMA (QUOTE 4)) (COMMA 7) (BACKQUOTE ((COMMA g)))) Evaluating this would similarly give something like (a 3 4 7 (BACKQUOTE ((COMMA g)))) If you don't believe this model is equivalent please send me a counterexample. (The only thing I can see won't work is if something EVALUATES to a list containing the symbols BACKQUOTE or COMMA, The evaluation does not occur at read-time, unless there's a #,, but then you can't pass ","'s up, so I don't think this is relevant. and I think we can pretend that's impossible, even though it's precisely what I really WANTED to do!)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 88 12:37:35 EST Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 14 Nov 88 09:16:59 PST Posted-Date: Mon, 14 Nov 88 09:11:39 PST Message-Id: <8811141711.AA04256@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA04256; Mon, 14 Nov 88 09:11:42 PST To: greenwald@stony-brook.scrc.symbolics.com Cc: common-lisp@sail.stanford.edu Subject: nested backquotes Date: Mon, 14 Nov 88 09:11:39 PST From: Don Cohen I think I understand your description (I think you left out a quote or two in the last element). Furthermore, I strongly suspect (but have not yet proven) that it is equivalent to mine. If so, my explanation seems easier to understand. The only problem was that you evidently did not understand what "matching" meant. It was very simple and did NOT require expanding the inner backquotes. Let me rephrase the model and see if you agree that it gives the same results as yours. Pretend that comma (comma@) reads like quote - ,x = (COMMA x) except that an expression may not be in the scope of more commas than backquotes. Similarly, suppose that backquote reads as the symbol BACKQUOTE consed onto the next read. So ``(a ,s ,',d ,,f `(,g)) reads as (BACKQUOTE BACKQUOTE a (COMMA s) (COMMA (QUOTE (COMMA d))) (COMMA (COMMA f)) (BACKQUOTE ((COMMA g)))) Now in order to evaluate that expression we find all forms that are in the scope of as many COMMAs as BACKQUOTEs. We discard the leading BACKQUOTE and replace such expressions (along with the matching COMMAs) with their values. In this case, the d and f are in the scope of 2 of each. The result is (BACKQUOTE a (COMMA s) (COMMA (QUOTE 4)) (COMMA 7) (BACKQUOTE ((COMMA g)))) Evaluating this would similarly give something like (a 3 4 7 (BACKQUOTE ((COMMA g)))) If you don't believe this model is equivalent please send me a counterexample. (The only thing I can see won't work is if something EVALUATES to a list containing the symbols BACKQUOTE or COMMA, and I think we can pretend that's impossible, even though it's precisely what I really WANTED to do!)  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 88 12:01:55 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Nov 88 08:43:14 PST Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 491891; Mon 14-Nov-88 11:41:01 EST Date: Mon, 14 Nov 88 11:40 EST From: Michael Greenwald Subject: backquote To: jonl@lucid.com, Greenwald@STONY-BROOK.SCRC.Symbolics.COM cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, donc@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: <8811140404.AA20070@bhopal> Message-ID: <19881114164032.1.GREENWALD@SWALLOW.SCRC.Symbolics.COM> Date: Sun, 13 Nov 88 20:04:56 PST From: Jon L White re: Could you forward this doubly nested example to me, so that the Genera reader >will< be able to parse it in future releases? I think it is ``(,@,@x). Believe it or not, one can "crank" the rules of CLtL p349-50 to come up with a meaning for it. Once you mention the example, it's not hard to believe at all. The bug in the Symbolics implementation is that it tries to optimize `(,@
) to just be . This isn't legal when you are inside another backquote, and might have a ",." or a ",@" that might have to be further expanded. I've submitted a patch. Lucid, Xerox, and VAXLISP get it "right" according to that meaning. Several others generate a read-time error (which is what I think Symbolics 7.0 does). I've seen some that parse it without error but subsquently generate wrong code. As to whether this was ever used in naturally occurring code -- I dunno. Ask QUUX (Guy L Steele). -- JonL -- P.S.: When trying to work out an example using the rules of CLtL p340-50, it's important to remember that the square-brackets are part of the syntax of that crufty litle production-rule language. They are not meta-meta-syntax. Right.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 14 Nov 88 03:27:31 EST Received: from Think.COM by SAIL.Stanford.EDU with TCP; 14 Nov 88 00:07:15 PST Return-Path: Received: from kulla.think.com by Think.COM; Mon, 14 Nov 88 02:27:39 EST Received: by kulla.think.com; Mon, 14 Nov 88 02:43:25 EST Date: Mon, 14 Nov 88 02:43:25 EST From: barmar@Think.COM Message-Id: <8811140743.AA22690@kulla.think.com> To: jonl@lucid.com Cc: Greenwald@stony-brook.scrc.symbolics.com, KMP@stony-brook.scrc.symbolics.com, donc@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: Jon L White's message of Sun, 13 Nov 88 20:04:56 PST <8811140404.AA20070@bhopal> Subject: backquote Specifically Re: ``(,@,@x) It does still get a read-time error on Genera 7.2. I also tried some variants. ``(,@,@x a) seems to work. ``(a ,@,@x) doesn't get an error, but I think it gets the wrong result. barmar  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Nov 88 23:24:37 EST Received: from lucid.com by SAIL.Stanford.EDU with TCP; 13 Nov 88 20:08:42 PST Received: from bhopal ([192.9.200.13]) by heavens-gate.lucid.com id AA05685g; Sun, 13 Nov 88 20:06:13 PST Received: by bhopal id AA20070g; Sun, 13 Nov 88 20:04:56 PST Date: Sun, 13 Nov 88 20:04:56 PST From: Jon L White Message-Id: <8811140404.AA20070@bhopal> To: Greenwald@STONY-BROOK.SCRC.Symbolics.COM Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, donc@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: Michael Greenwald's message of Fri, 11 Nov 88 12:57 EST <19881111175759.2.GREENWALD@SWALLOW.SCRC.Symbolics.COM> Subject: backquote re: Could you forward this doubly nested example to me, so that the Genera reader >will< be able to parse it in future releases? I think it is ``(,@,@x). Believe it or not, one can "crank" the rules of CLtL p349-50 to come up with a meaning for it. Lucid, Xerox, and VAXLISP get it "right" according to that meaning. Several others generate a read-time error (which is what I think Symbolics 7.0 does). I've seen some that parse it without error but subsquently generate wrong code. As to whether this was ever used in naturally occurring code -- I dunno. Ask QUUX (Guy L Steele). -- JonL -- P.S.: When trying to work out an example using the rules of CLtL p340-50, it's important to remember that the square-brackets are part of the syntax of that crufty litle production-rule language. They are not meta-meta-syntax.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 13 Nov 88 18:59:55 EST Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Nov 88 15:38:05 PST Received: from SWALLOW.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 491650; 13 Nov 88 18:34:25 EST Date: Sun, 13 Nov 88 18:34 EST From: Michael Greenwald Subject: backquote To: donc@vaxa.isi.edu, common-lisp@sail.stanford.edu In-Reply-To: <8811111818.AA01792@vaxa.isi.edu> Message-ID: <19881113233411.3.GREENWALD@SWALLOW.SCRC.Symbolics.COM> Date: Fri, 11 Nov 88 10:18:20 PST From: Don Cohen First, I was hoping for a clear statement of what nested backquotes meant. Here's my current theory - the result of experimentation. I don't see how to interpret CLtL to mean this (innermost backquote expanded first??), but at least maybe someone in the know can either confirm my theory (and provide the mapping from CLtL) or correct it (and still provide the mapping): First, you should distinguish between the two cases of nested backquotes with an intervening comma, and nested backquotes without an intervening comma. The former case is unambigously specified by CLtL. The latter isn't (the outer backquote will capture the intermediate state of the computation of the inner backquote.) Yours is an example of the latter case. When you evaluate a backquote expression (oh, all right, the result of reading one evaluates as if ...), you throw away the backquote (we're always evaluating the "outermost" backquote now!), find all the "matching" commas You can't do this without expanding the inner nested backquotes first. (which must all be innermost commas, although not all innermost commas match this backquote!) and replace them with the results of evaluating them. Leave all other backquotes and commas (and everything else) alone! Thus ``(a ,s ,',d ,,f `(,g)) -- -- results in evaluation of the underlined expressions, yielding something like `(a ,s ,'4 ,7 `(,g)) ,@ is just like , except that you throw out an outer pair of parens. Is that right? No (it's not outright "wrong"). It is sort of backwards. CLtL states "If the backquote syntax is nested, the innermost backquoted form should be expanded first." This means that you can't start stripping commas until all inner backquotes have been expanded. At any given level of expansion you use the outtermost comma first. The result of expanding a backquote is only defined after evaluation, so the exact details of the list structure returned by `` will vary from implementation to implementation, however, the result of evaluating the value of a `` should be consistent. In your example what's happening is something like this: Using the transformation rules at the top of page 350 this means that the interpretation of your example proceeds as follows: (forms like <...>, inside angle brackets are uninterpreted expressions inside a backquote. Note that there's an implicit backquote before a <. You cannot intrepet the body of a <...> unless there are no <>'s inside it.) ``(a ,s ,',d ,,f `(,g)) <`(a ,s ,',d ,,f `(,g))> ;; now we have a problem. The inner backquote is going to produce a ;; form that "when evaluated will ...", but the outer backquote is ;; telling us not to actually evaluate that form. So we exposing the ;; innards of whichever reader we happen to be using. ;; For the sake of pedagogy we choose a very simple backquote ;; implementation. We use bq-list instead of ;; list so that the pretty printer will be able to print out these lists ;; in backquote syntax. ;; So the next step is: <(bq-list <,s> <,',d> <,,f> <`(,g)>)> <(bq-list 'a <,s> <,',d> <,,f> <`(,g)>)> <(bq-list 'a s <,',d> <,,f> <`(,g)>)> ;; now, the rules tell us how to take off the outermost "," <(bq-list 'a s ',d <,,f> <`(,g)>)> ;; ditto <(bq-list 'a s ',d ,f <`(,g)>)> <(bq-list 'a s ',d ,f (bq-list <,g>))> <(bq-list 'a s ',d ,f (bq-list g))> ;; now we can interpret <(bq-list ...)> relative to the outer backquote (bq-list <'a> <',d> <,f> <(bq-list g)>) ;; the interpretation of , <'a>, and are done in one step here ;; because I'm getting bored... (bq-list 'bq-list ''a 's <',d> <,f> <(bq-list g)>) ;; this should help illustrate what >really< happened to <'a> in all of ;; its boring steps. (bq-list 'bq-list ''a 's (list 'quote <,d>) <,f> <(bq-list g)>) (bq-list 'bq-list ''a 's (list 'quote d) <,f> <(bq-list g)>) (bq-list 'bq-list ''a 's (list 'quote d) f <(bq-list g)>) (bq-list 'bq-list ''a 's (list 'quote d) f (list 'bq-list 'g)) Say that BQ-LIST acts exactly like LIST, except that the pretty printer knows how to print a list whose car is BQ-LIST by printing a leading backquote, and stripping one quote from each elt of the list, and if there's no quote to strip, inserting a comma. Then the result of the reading and evaluating your example (if D is 4 and F is 7) read of ``(a ,s ,',d ,,f `(,g)) => (bq-list 'bq-list ''a 's (list 'quote d) f (list 'bq-list 'g)) Eval of that => (bq-list 'a s '4 7 (bq-list g)) Which would be printed `(a ,s 4 7 `(,g)) So the illusion is that it is matching inner-most comma's to the outermost backquote, but in fact it is behaving roughly the way I describe, and CLtL defines. (I wasn't very careful about this, so I might have made some mistakes - it's an awfully baroque transformation). A more common case is where the nested backquote is inside a comma, so that the backquote implementation isn't exposed in the final result.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Nov 88 21:20:23 EST Received: from argus.Stanford.EDU by SAIL.Stanford.EDU with TCP; 11 Nov 88 18:04:22 PST Received: from Riverside.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by argus.Stanford.EDU with TCP; Fri, 11 Nov 88 17:57:40 PST Received: from F.ILA.Dialnet.Symbolics.COM (FUJI.ILA.Dialnet.Symbolics.COM) by Riverside.SCRC.Symbolics.COM via DIAL with SMTP id 293976; 11 Nov 88 21:01:28 EST Date: Fri, 11 Nov 88 19:08 EST From: Robert W. Kerns Subject: Re: backquote To: ssmith@nrtc.northrop.com, donc@vaxa.isi.edu Cc: common-lisp@sail.stanford.edu In-Reply-To: The message of 10 Nov 88 19:46 EST from Stephen P. Smith Message-Id: <19881112000850.2.RWK@F.ILA.Dialnet.Symbolics.COM> Date: Thu, 10 Nov 88 16:46:32 -0800 From: "Stephen P. Smith" From your question about the CLtL reference on page 350: It was also never clear to me without lots of experimentation what such constructs as ,',@ should do either (or that they were really allowed). Well, ,',@X is basically nonsense, unless you KNOW that X is exactly one element long. Otherwise you're passing the wrong number of arguments to the QUOTE special form. If you thin kyou want ,',@, you probably want ,@',X. One way to look at ,@',X and ,',X is that these evaluate the X from the OUTER backquote's context. Remember, the outer one is actually BUILDING the inner one. The inner one being built is then "commafying" a quoted list.  Received: from SAIL.Stanford.EDU (TCP 1200000013) by AI.AI.MIT.EDU 11 Nov 88 13:39:18 EST Received: from vaxa.isi.edu by SAIL.Stanford.EDU with TCP; 11 Nov 88 10:20:46 PST Posted-Date: Fri, 11 Nov 88 10:18:20 PST Message-Id: <8811111818.AA01792@vaxa.isi.edu> Received: from LOCALHOST by vaxa.isi.edu (5.59/5.51) id AA01792; Fri, 11 Nov 88 10:18:59 PST To: common-lisp@sail.stanford.edu Subject: backquote Date: Fri, 11 Nov 88 10:18:20 PST From: Don Cohen First, I was hoping for a clear statement of what nested backquotes meant. Here's my current theory - the result of experimentation. I don't see how to interpret CLtL to mean this (innermost backquote expanded first??), but at least maybe someone in the know can either confirm my theory (and provide the mapping from CLtL) or correct it (and still provide the mapping): When you evaluate a backquote expression (oh, all right, the result of reading one evaluates as if ...), you throw away the backquote (we're always evaluating the "outermost" backquote now!), find all the "matching" commas (which must all be innermost commas, although not all innermost commas match this backquote!) and replace them with the results of evaluating them. Leave all other backquotes and commas (and everything else) alone! Thus ``(a ,s ,',d ,,f `(,g)) -- -- results in evaluation of the underlined expressions, yielding something like `(a ,s ,'4 ,7 `(,g)) ,@ is just like , except that you throw out an outer pair of parens. Is that right? ---------------- Next some comments on the "solutions". What they have done is to change the protected-+ macro from what I would have written originally into something else - my ((x ,x) (y ,y)) has become a mapcar. In other words, as long as the expansion has to be evaluated again, we can replace what we really want with something else which will later evaluate to the same thing. This works, but starts to sacrifice some of the clarity which was the reason for backquote in the first place. I think it would be a lot easier if you COULD "pass a 'free' comma around", and more generally, if you could directly express when each expression should be evaluated, i.e., which backquote it went with. Here's a "labelled backquote" macro that does this. Reviews are welcome. I describe it as a regular macro, not a readmacro. I wonder whether that's important. Perhaps backquote could be extended in this direction. ---------------- (LBQ