Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "B. Pym" <Nobody447095@here-nor-there.org>
Newsgroups: comp.lang.lisp,comp.lang.scheme
Subject: Re: Why does CL separate variables and functions namespaces?
Date: Sat, 21 Sep 2024 14:04:15 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 63
Message-ID: <vcmjou$1kebn$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Injection-Date: Sat, 21 Sep 2024 16:04:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="75bf4db5387dcb76189623713453f22d";
	logging-data="1718647"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+kXXOETXphFTLa7iwOp2Xd"
User-Agent: XanaNews/1.18.1.6
Cancel-Lock: sha1:mG7XRNVLy2F1Fv7bR7kAZcHl19s=
Bytes: 3010

Javier wrote:

> I'm wondering whoose motivations were taken when designing the
> namespace of Lisp, and why functions names and data names are not
> treated the same.
> 
> For example, in Scheme:
> 
> ((car (list +)) 5 6)
> 
> is equivalent to:
> 
> (funcall (car (list #'+)) 5 6)
> 
> in CL.

Daniel Weinreb, 24 Feb 2003:

Having separate "value cells" and "function cells" (to use
the "street language" way of saying it) was one of the most
unfortunate issues. We did not want to break pre-existing
programs that had a global variable named "foo" and a global
function named "foo" that were distinct.  We at Symbolics
were forced to insist on this, in the face of everyone's
knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all
the specific things like this, but if we had had fewer
compatibility issues, I think it would have come out looking
more like Scheme in general.

Daniel Weinreb, 28 Feb 2003:

Lisp2 means that all kinds of language primitives have to
exist in two versions, or be parameterizable as to whether
they are talking about the value cell or function cell. It
makes the language bigger, and that's bad in and of itself.

Paul Graham:

Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988?

Dick Gabriel:

Common Lisp is a significantly ugly language.  If Guy and I
had been locked in a room, you can bet it wouldn't have
turned out like that.

Dick Gabriel:

Common LISP just was never designed to be a commercially
viable LISP.  It was intended to serve as a compromise between
the manufacturers of LISP machines and other vendors of LISP
products.  Never did we think of it as an industrial strength
system...  So, to the extent that ANSI's ongoing efforts to
standardize on Common LISP exercise some influence over how LISP
is accepted in the world at large, I anticipate a disaster.

Paul Graham:

The good news is, it's not Lisp that sucks, but Common Lisp.