Re: scheme seems neater
From: Matthew Danish (mdanish_at_andrew.cmu.edu)
Date: Wed, 7 Apr 2004 14:53:25 -0400
On Wed, Apr 07, 2004 at 07:38:11PM +0200, Marcin 'Qrczak' Kowalczyk wrote:
> In Scheme function objects are a special case of values, just as function
> bindings are a special case of value bindings.
> In Lisp function objects are also a special case of values, but function
> bindings are not a subset of value bindings - they are made disjoint.
Keep in mind that ordinary variables may also be bound to functions.
> It only makes sense to put numbers as arguments of +, but Lisp doesn't
> enforce it by putting variables holding numbers in a separate namespace.
> So having only a subset of values legal is not enough to justify separate
In a statically typed language, it is conceivable to imagine a separate
namespace for every type:
(let ((a 1)
(setf a (+ a 1)) ;; A the integer
(setf a (string a))) ;; A the string
Of course, Lisp is not like this, but there is a distinction which can
be statically determined: syntactic position. Neither in Scheme nor in
CL is ((not-a-fn-value) ...) a valid program; but in CL this can be
determined statically, and in Scheme it can only be found at runtime.
In addition, in a conforming CL program, by looking up the function name
in the function namespace, it is known that if the name is bound there
then it must be bound to a function object. There is no such guarantee
> Separate namespaces for two kinds of things don't cause trouble (other
> than perhaps human confusion) in cases the usage of the kinds is disjoint.
> For example C types and C values are never interchangeable. But it's
> not the case for functions and other values: it does make sense to have
> functions as arguments to other functions, and to call functions which
> came as parameters or are computed by function calls. Separate namespaces
> make it harder.
However this is partially incorrect: while it does make sense to have
higher-order functions (and Lisp-2 does not make this difficult), the
important distinction actually lies in the syntax of forms, not in the
type of objects. Without knowing anything about the runtime values
involved, it is quite clear that the first element of a function form
must be a function. CL takes this fact and makes it a part of the
language, along with macro and special forms which also can (and must)
be determined statically. So my question is: why would you want the
names of functions and the names of variables to be in the same
namespace, when the primary use of function names is to appear where a
variable name would rarely want to appear?
Consider the case of class names: why should a class named FOO prevent
the use of variables named FOO? The only time I would be referring the
class by the name FOO is in contexts which expect a class name. If, on
the rare occasion I need to get the class object which is bound to the
class name FOO, there is FIND-CLASS.
> I understand how separate namespaces make non-hygienic macros a smaller
> problem, and that some people like punning, but I can't agree that those
> namespaces should be separated because of a fundamental difference between
> functions and other objects. At least in a functional language, where
> functions *are* objects.
Remember, it is function /names/ which are separated. Function objects
don't have anything to do with namespaces. The distinction is a
syntactic one. When we write (NAME ...) we want NAME to be bound to a
function. The separate namespace guarantees it won't be bound to any
other type of object in a conforming program.
-- ; Matthew Danish <firstname.lastname@example.org> ; OpenPGP public key: C24B6010 on keyring.debian.org ; Signed or encrypted mail welcome. ; "There is no dark side of the moon really; matter of fact, it's all dark."