In article <···@soi.UUCP> ····@soi.UUCP (Chip Morris) writes:
[Reference to <·················@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.
In article <···@marob.MASA.COM>, ·····@marob.MASA.COM (John Cowan) writes:
> In article <···@soi.UUCP> ····@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: ········@harvard.harvard.edu
UUCP: ...!harvard!soi!chip Phone: (617) 497-5054