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.
What are the advantages of this way of treating functions? Can you
present me an example of such advantage?
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.
Functions are considered to be operator-like in Lisp. Operators cannot
resemble data because in general, operators can work with syntax.
We could imagine a "universal Lisp dialect" in which there are three
entities: special operators, functions and variables. Special operators
are resolved in the leftmost position of a list. Every expression has
some kind of special operator. The special operator CALL invokes a
function, e.g. (CALL X X) invokes function X and passes X to it. X is
an ordinary variable or expression to be evaluated.
This is inconvenient if you are doing a lot of programming with
function calls.
What Common Lisp does is migrate the functions to the operator
namespace, so that CALL is unnecessary. (And FUNCALL is introduced as
an ordinary function for when a function is to be called from a memory
location such as a variable).
What Scheme does is merge the operator and variable namespace. It
eliminates the CALL operator that way. But it's now possible to write
some meaningless expressions, like taking the value of a special
operator, e.g. (set! foo let). What is the value of LET? Or worse:
(set! let 42). Under the Common Lisp approach we don't have this
wrinkle: you cannot express assignment to a special operator. However,
advocates of the Scheme approach to namespaces regard FUNCALL as a
wrinkle.
Pick your poison, or wine, however you want to look at it.
> For example, in Scheme:
>
> ((car (list +)) 5 6)
>
> is equivalent to:
>
> (funcall (car (list #'+)) 5 6)
>
> in CL.
Whereas in CL you can do things like:
(defclass automobile () ((engine :accessor engine)))
(defclass engine () ((automobile :accessor automobile)))
Now you can have something like
(defmethod verify-connected ((engine engine) (automobile automobile))
(and (eq (engine (automobile engine)) engine)
(eq (automobile (engine automobile)) automobile)))
ENGINE is a class name, as well as a variable name and a slot accessor.
In spite of these overloaded contexts, it's all quite clear. We have a
method here which takes two arguments, an engine of type engine and an
automobile of type automobile. It checks whether the engine associated
with the automobile of this engine is in fact that engine, and whether
the automobile associated with the engine of this automobile is that
automobile.
> What are the advantages of this way of treating functions? Can you
> present me an example of such advantage?
See above. The use of a name in multiple contexts leads to simple
clarity. Without it, you have to get into the awkward business of
inventing names that you do not care to invent.
If having a class ENGINE precluded you from having a variable called
ENGINE which is an instance of that class, it would be irksome. It
would be equally irksome if you couldn't have an accessor called ENGINE
for some other class that has an association with ENGINE.
Kaz Kylheku wrote:
[...]
Ok, it's much clearer to me right now. Thank you.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Why does CL separate variables and functions namespaces?
Date:
Message-ID: <87lkr08lyn.fsf@qrnik.zagroda>
"Kaz Kylheku" <········@gmail.com> writes:
> What Scheme does is merge the operator and variable namespace. It
> eliminates the CALL operator that way. But it's now possible to write
> some meaningless expressions, like taking the value of a special
> operator, e.g. (set! foo let). What is the value of LET? Or worse:
> (set! let 42). Under the Common Lisp approach we don't have this
> wrinkle: you cannot express assignment to a special operator.
No, you can express similar nonsense in Common Lisp.
(setf (symbol-function 'foo) #'let)
(defun let ())
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
From: Pascal Costanza
Subject: Re: Why does CL separate variables and functions namespaces?
Date:
Message-ID: <4hheb1F1olq5nU1@individual.net>
Marcin 'Qrczak' Kowalczyk wrote:
> "Kaz Kylheku" <········@gmail.com> writes:
>
>> What Scheme does is merge the operator and variable namespace. It
>> eliminates the CALL operator that way. But it's now possible to write
>> some meaningless expressions, like taking the value of a special
>> operator, e.g. (set! foo let). What is the value of LET? Or worse:
>> (set! let 42). Under the Common Lisp approach we don't have this
>> wrinkle: you cannot express assignment to a special operator.
Neither (set! foo let) nor (set! let 42) are meaningful under R5RS given
its default bindings. (set! foo let) is not meaningful because 'let is
not a variable (see 3.1). Likewise, (set! let 42) is not meaningful
because again, 'let is not a variable.
> No, you can express similar nonsense in Common Lisp.
> (setf (symbol-function 'foo) #'let)
> (defun let ())
In the case of Common Lisp, these two forms do not only lack meaning,
they are actually erroneous. #'let or (function let) is an error because
ANSI Common Lisp clearly states that "it is an error to use function on
a symbol that denotes a macro or special form". See the entry for
'function. The second form is an error because of Section 11.1.2.1.2 in
the HyperSpec.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
In article <························@b28g2000cwb.googlegroups.com>,
"Javier" <·······@gmail.com> 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.
Why don't you read Kent Pitman's classic paper on Lisp-1 vs. Lisp-2?
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Kent M Pitman
Subject: Re: Why does CL separate variables and functions namespaces?
Date:
Message-ID: <uzmfh6npj.fsf@nhplace.com>
"Javier" <·······@gmail.com> writes:
> 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.
This is adequately discussed already elsewhere on this newsgroup, but...
Partly because that's the way people's brains work.
Partly for efficiency.
Partly for tradition.
Partly for aesthetics.
> For example, in Scheme:
>
> ((car (list +)) 5 6)
>
> is equivalent to:
>
> (funcall (car (list #'+)) 5 6)
>
> in CL.
Scheme has different efficiency, tradition, and aesthetics.
(Yes, I deliberately didn't comment on Scheme users' brains.)
> What are the advantages of this way of treating functions? Can you
> present me an example of such advantage?
There was an internal X3J13 document called
"Issues of Separation in Function Cells and Value Cells"
which Dick Gabriel and I wrote for the committee to help in making
the decision. Gabriel and I were on opposite sides of the issue,
so we did our best to present both sides of the issue. It was boiled
down and later republished as
"Technical Issues of Separation in Function Cells and Value Cells",
which you can find on the web as
http://www.nhplace.com/kent/Papers/Technical-Issues.html
From: Hrvoje Blazevic
Subject: Re: Why does CL separate variables and functions namespaces?
Date:
Message-ID: <e8vklf$q54$1@ss408.t-com.hr>
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.
>
> What are the advantages of this way of treating functions? Can you
> present me an example of such advantage?
>
Most of the issues involved are nicely described in LiSP book by C.
Queinnec in chapters on Lisp-1 and Lisp-2. But of-course, mostly from
the perspective of "(Yes, I deliberately didn't comment on Scheme users'
brains.)" :-)
-- Hrvoje