Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!bloom-beacon!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.lang.lisp
Subject: Re: #( syntax
Message-ID: <20282@news.Think.COM>
Date: 20 May 89 01:47:44 GMT
References: <8905120152.AA17406@anaconda.stanford.edu> <432@soi.uucp> <655@marob.masa.com> <433@soi.uucp>
Sender: news@Think.COM
Reply-To: barmar@kulla.think.com.UUCP (Barry Margolin)
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 46

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