rit@ANACONDA.STANFORD.EDU (Jean-Francois Rit) (05/12/89)
I came on a strange, to me, feature of coral common lisp 1.2.1: the following expression (setq toto #(1 2 3)) makes lisp return an error (cannot eval). However (setq toto '#(1 2 3)) works, and toto is actually the right vector object. Both formulation work in lucid. So what's happening, is the coral implementation wrong? Is it reasonable to consider the quoted version a common denominator? JF Jean-Francois Rit Tel: (415) 723 3796 CS Dept Robotics Laboratory e-mail: rit@coyote.stanford.edu Cedar Hall B7 Stanford, CA 94305-4110
barmar@think.COM (Barry Margolin) (05/12/89)
In article <8905120152.AA17406@anaconda.Stanford.EDU> rit@ANACONDA.STANFORD.EDU (Jean-Francois Rit) writes: > >I came on a strange, to me, feature of coral common lisp 1.2.1: >the following expression (setq toto #(1 2 3)) makes lisp return an error >(cannot eval). However (setq toto '#(1 2 3)) works, and toto is actually the >right vector object. >Both formulation work in lucid. >So what's happening, is the coral implementation wrong? Is it reasonable to >consider the quoted version a common denominator? Both implementations conform to CLtL, but Lucid's behavior is due to an extension. See pp.54-55 in CLtL. Basically, what it says is that portable programs may only depend on the following data types being evaluable: numbers, characters, strings, bit-vectors, symbols, and lists. It says that "it is an error" to evaluate anything else, which means that the behavior is implementation-dependent (it would be just as valid for an implementation to evaluate #(foo bar) into NIL). By the way, the ANSI Common Lisp committee voted a few months ago to change this. In the draft standard, we currently plan to specify that everything but a list or a symbol is self-evaluating. It was originally left undefined in order to allow implementors to experiement with alternate evaluation ideas. But as far as we can tell, no one ever did; the only extensions are the ones that self-evaluate various non-standard forms, and it's common enough that we decided to mandate it. Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
chip@soi.UUCP (Chip Morris) (05/12/89)
In article <8905120152.AA17406@anaconda.Stanford.EDU>, ~rit@ANACONDA.STANFORD.EDU (Jean-Francois Rit) writes: > > I came on a strange, to me, feature of coral common lisp 1.2.1: > the following expression (setq toto #(1 2 3)) makes lisp return an error > (cannot eval). However (setq toto '#(1 2 3)) works, and toto is actually the > right vector object. > Both formulation work in lucid. > So what's happening, is the coral implementation wrong? Is it reasonable to > consider the quoted version a common denominator? Coral is OK, and so is Franz Allegro. If a form isn't self-evaluating, i.e. doesn't return itself as a value, then in general it must be quoted. CLtL (Steele) says in section 5.1.1 what the self-evaluating forms are: numbers, characters, strings,bit-vectors, () and NIL, as well as all keywords. So technically anything else must be quoted, including arrays, vectors, and structures. See also "Common Lisp, The Reference", page 665. -- Chip Morris, Senior Engineer US Mail: Software Options, Inc., 22 Hilliard St., Cambridge MA 02138 Internet: chip%soi@harvard.harvard.edu UUCP: ...!harvard!soi!chip Phone: (617) 497-5054
cowan@marob.MASA.COM (John Cowan) (05/13/89)
In article <8905120152.AA17406@anaconda.Stanford.EDU> rit@ANACONDA.STANFORD.EDU (Jean-Francois Rit) writes: > >I came on a strange, to me, feature of coral common lisp 1.2.1: >the following expression (setq toto #(1 2 3)) makes lisp return an error >(cannot eval). However (setq toto '#(1 2 3)) works, and toto is actually the >right vector object. >Both formulation work in lucid. >So what's happening, is the coral implementation wrong? Is it reasonable to >consider the quoted version a common denominator? Both systems are correct. The Common Lisp standard does not require general vectors to be self-quoting (numbers, characters, strings, and bit-vectors only). However, any given implementation is allowed to define semantics for extending evaluation to forms other than symbols, lists, and self-quoting objects. Lucid evidently defines general vectors as self-quoting (valid extension), whereas Coral barfs on evaluation of general vectors. To be safe and portable, always quote general vectors explicitly.
cowan@marob.MASA.COM (John Cowan) (05/16/89)
In article <432@soi.UUCP> chip@soi.UUCP (Chip Morris) writes: [Reference to <8905120152AA17406@anaconda.Stanford.EDU>, which explains that Lucid CL accepts general vectors as self-quoting, whereas Coral and Franz Allegro don't] >Coral is OK, and so is Franz Allegro. If a form isn't >self-evaluating, i.e. doesn't return itself as a value, then in >general it must be quoted. CLtL (Steele) says in section >5.1.1 what the self-evaluating forms are: numbers, characters, >strings,bit-vectors, () and NIL, as well as all keywords. So >technically anything else must be quoted, including arrays, vectors, >and structures. See also "Common Lisp, The Reference", page 665. CLtL tells us that a CL implementation may extend the class of evaluatable constructions beyond the standard variables, function/macro calls, and self-quoting objects. It is conforming for an implementation to accept general vectors as self-quoting; however, it is >not< portable for source code to depend on this behavior.
chip@soi.UUCP (Chip Morris) (05/16/89)
In article <655@marob.MASA.COM>, cowan@marob.MASA.COM (John Cowan) writes: > In article <432@soi.UUCP> chip@soi.UUCP (Chip Morris) writes: >>If a form isn't self-evaluating, i.e. doesn't return itself as a >>value, then in general it must be quoted. > As many have pointed out, "must be" should be "must be if you want portable code". Because I maintain a fairly large program simultaneously on Symbolics, Lucid and Coral Allegro, I fall into the trap of reflexively equating the two. Our group simply _must_ code in strict Common Lisp, since just about every chance for difference will be instantiated between some pair of implementations. Which brings me to my real point: when will the sociology (economics, politics ...) of programming languages catch up with "Common" Lisp? The ambiguities in the language were, theoretically, to allow experimentation with alternatives, presumably to improve the language definition. But with larger and larger commercial systems depending on particular implementations, it seems we may soon be in the same old spot: there won't be enough "common" about Common Lisp to fulfill even the minimum requirements of portability, one of which must be that economic costs of a port are relatively small compared to the benefits. We will be in the usual situation: "My program runs on whatever machine implementation X runs on" instead of "My program runs on whatever machine Common Lisp runs on". Already Franz salesman are running into problems luring Lucid customers over to Allegro because the Lucid users depend heavily on built-in features of Lucid. And Franz is busy building in its own idiosyncracies. If I may, I will venture to say that any time Uncle Sam puts his imprimature on a language (or any other large software venture) and pumps a lot of money into it, you can bet that an unhealthy, unstable situation will result. Is Common Lisp the "right" language for its application domain? These comments all my own, and do not necessarily reflect my company's policy. -- Chip Morris, Senior Engineer US Mail: Software Options, Inc., 22 Hilliard St., Cambridge MA 02138 Internet: chip%soi@harvard.harvard.edu UUCP: ...!harvard!soi!chip Phone: (617) 497-5054
barmar@think.COM (Barry Margolin) (05/20/89)
In article <433@soi.uucp> chip@soi.UUCP (Chip Morris) writes: >Which brings me to my real point: when will the sociology (economics, >politics ...) of programming languages catch up with "Common" Lisp? >The ambiguities in the language were, theoretically, to allow >experimentation with alternatives, presumably to improve the language >definition. Actually, most of the ambiguities in the language are there to permit implementations on conventional processor architectures to get reasonable performance, so that Lisp Machine vendors would not have an unfair advantage in the Lisp marketplace. For instance, a CL implementation is not required to check that arguments to standard functions are of the required types, nor is it required to signal an error if you try to use an unbound variable. Some of these "ambiguities" also permit implementations to extend the language (for instance, CLtL doesn't say what happens if a function is called with more arguments than are specified in the book, so this is license for an implementation to add its own optional or keyword arguments to a standard function); however, that is not their primary purpose. There are a few hooks that were explicitly left for experimentation; the only ones I can think of are evaluation of non-standard data types, and putting atoms in the body of a LOOP. Both these cases are being resolved in the ANSI Common Lisp standardization effort. In the first case we're proposing that all objects other than symbols and lists be self-evaluating, and in the second case we've adopted a version of the MIT LOOP macro into our draft. There has been quite a bit of discussion within X3J13 regarding restricting implementations from extending the language. Proposals to include these restrictions in the draft standard were voted down, however. My feeling is that it is not possible to include such restrictions while still retaining some of the flexibilities. For instance, if we don't require implementations to check that functions are called with the correct number of arguments, we can't complain about an implementation that happens to do something reasonable in some cases when the wrong number of arguments are supplied. Also, if we don't permit implementations to defined the behavior when the wrong type of argument is supplied to a function then an implementation that defines this to signal an error would be in violation of the standard! Barry Margolin Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar