·····@kastle.Princeton.EDU (Matthias Blume) writes under a different
subject header:
In article <·····················@dcs.warwick.ac.uk>,
·····@dcs.warwick.ac.uk (CRAIG LEE EALES) writes:
|> Also as only the syntatic keywords are reserved does this mean
|> that all the procedures (+ , * , etc) can all be re-assigned as
|> variables or can identifiers be associated with values and
|> lambda expressions (like lisp)?
Yes, *, + and friends are all simply variables. This is
one of the main advantages of Scheme over Lisp that it
unifies the concepts ``function-definition'' and
``variable-binding''.
Some Lisp dialects in the older days didn't make this distinction
either, it was added for performance and convenience reasons (although
performance may no longer be an argument - see below). LISP 1.5,
Common Lisp and [Portable] Standard Lisp have the distinction, but
Cambridge Lisp and Lisp/VM don't have it, for example.
Personally I have zero problems with the Common Lisp way of having
different name spaces for operators and variables (and also types). I
even consider it as a (nice but not vital) feature to be able to call
a function argument e.g. "LIST", while retaining the function binding
of LIST. No flames please: sometimes words like LIST are perfectly
adequate and self-describing as parameter names. Also, the
distinction between functions and variables is one I as a programmer
make anyway - but that may be only because I don't have had enough
exposure to languages like Scheme.
On the other hand, I have to agree that the Scheme way is simpler and
therefore prettier. But IMHO the value of this advantage is more
quantitative than qualitative - it may make reasoning about program
semantics simpler, but not that much. For example, you simply have to
treat *some* operator names specially, namely those of the special
operators (don't tell me Scheme doesn't have QUOTE :-), so you lose a
bit of the new orthogonality right away.
The net effect is that all elements of a function call
including the operator iitself are evaluated according to
the same rules. This simplifies the whole semantics of the
language and makes it more general.
Simplifies yes, makes it more general... well, you can always obtain
the Scheme semantics in Common Lisp by using FUNCALL. There is no
direct equivalent to LETREC, but you can use LABELS and LET.
Citing Julian Padget [Padget, 1988]:
"[This issue] has been the subject of much controversy. Early
Lisps were ambivalent on the issue of whether the value of a
name in operator position was different from the value of the
same name in an operand position. That they should be the
same is not explicitly stated in the theory of lambda
calculus, but it is clear that (x x) means x[y:=x], or apply
the value of x to itself. Some Lisps, (Scheme, Lisp/VM,
Cambridge Lisp, T) have sought to maintain this consistency of
resolution whilst other Lisps have preferred to maintain the
ambiguity (MacLisp, InterLisp, Franz Lisp, Common Lisp) on the
grounds of efficiency and difficulties in macro expansion.
The first objection is refuted both in the experience of the
implementors of the, so called, single value Lisp systems and
in recent experiments by Gabriel and Fahlman [Gabriel, 1987].
[... the second objection is less interesting today - SL]"
My personal opinion is that while "single value" is the only right
solution for Scheme, I am also happy with the two-(or more-)namespace
solution in Common Lisp. Each one fits well with the design goals of
the respective language.
EuLisp of course "fixed" this Common Lisp deficiency in favour of the
Scheme way.
Regards,
--
Simon Leinen.
Laboratoire d'Intelligence Artificielle
Ecole Polytechnique Federale de Lausanne
[Padget, 1988] Julian Padget, "Three Uncommon Lisps", First
Internation Workshop on LISP Evolution and Standardization,
Paris 1988.
[Gabriel, 1987] private communication between J. Padget and rpg.