Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!ames!pasteur!ucbvax!decwrl!decvax!ima!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: #( syntax
Message-ID: <40510@think.UUCP>
Date: 12 May 89 06:53:18 GMT
References: <8905120152.AA17406@anaconda.Stanford.EDU>
Sender: news@think.UUCP
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 33

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