Binding, etc.

[wilensky%larch.Berkeley.EDU@BERKELEY.EDU (Robert Wilensky)]

(I sent this a while ago, but I believe the mail system ate it.  Apologies
in advance if you received it already).

Some time ago I sent around a flame on the issue of the ``binding''
terminology in Common LISP.  My contention is that the whole notion of
binding as used in the LISP community is not particularly coherent.  The
best solution to the many problems is to eliminate this usage altogether.
While this may seem radical at first, I believe it is the only consistent
solution, and the result is actually quite simple.  

Basically, the gripe is that the usage of the terms ``binding'', ``bound'',
``bind'', etc. confuse implementation issues with semantic issues (more on
this below).  My proposal is to say that applying a lambda, etc. causes a
new VARIABLE to be created corresponding to each formal parameter (as
opposed to a new binding for a variable).  It also happens to ASSIGN a value
to that variable.  In general, variables may or may not have assignments,
and SETQ changes assignments.  

Rather than talk about bindings, etc., we now talk about how occurrences of
symbols refer to variables.  For example, there is no longer a notion of a
``free variable'', but merely a free occurrence of a symbol.  The rules
about special variables are rules about which variable a free occurrence of
a symbol refers to.  Similarly, using a symbol at the top level to refer to
a variable refers to the global variable associated with that symbol.

Note that the only change in Common LISP (other than the documentation) that
needs to be changed to accommodate my proposal to rename some misnamed
functions.  For example, ``boundp'' (which has nothing whatsoever to do with
bindings, under any interpretation) should be called ``assignp'';
``makunbound'' becomes ``makunassigned'' (or, even more daringly,
``make-unassigned'').  There are a few others...

I wrote Common LISPcraft using this terminology, and I believe it worked
very well.

Here's a copy of my old flame, fyi:

----------------------------------------

There appears to be considerable terminological confusion in Commmon LISP.
Here are two examples:

(1) The use of the terms ``binding'', ``bound'' and ``unbound''.  

On p. 55 we are told variable can be ``assigned to, as by `setq' or bound,
as by `let'. ''  However, a binding is defined as a particular parameter
instance (p. 36).  Moreover, a special variable (and only a special
variable)  can be ``unbound''.  It is also rather hard to avoid saying that
a special variable is ``bound'' when it has a value, as ``boundp'' will
return true in this case.

Unfortunately, these meanings are in conflict.  For example, they allow for
the case in which a variable is ``bound'' but has no ``binding'' (namely,
when the reference is to the global value); the variable can be ``unbound'',
but have a binding (as you point out, when it is ``bound'', but valueless.)
If you simply refuse to say that a variable without any bindings is bound
(even though ``boundp'' of it is true), you are then committed to saying
that it is not `bound'', not ``unbound'', and has no ``binding'' (although,
of course, it has a perfectly fine and accessible value).  In addition, a
``bound variable'' appears to mean a variable that currently has a binding
(as in, ``a variable bound by `let' ''), although, of course, such a bound
variable may very well be ``unbound''.

In addition, there appears to be confusion as to whether a variable or a
binding is something that is referenced, etc.  For example, p. 37 talks
about the scope and extent of special bindings, whereas p. 38 talks about
the scope and extent of special variables.  it is unclear what a reference
to a variable that happens to be a parameter might be, other than a
reference to its current binding, since this is an fact the particular
instance of that paramater that is in force.  For example, p. 55 talks about
``the reference ... to the variable specified by the binding''.  It is not
clear how a particular instance of a parameter can specify a variable.  Nor
would this seem desirable.  If two different invocations of the same
function are considered to have the same variables but with different
bindings, then one would not want to reference any variable, but rather, the
current bindings of those variables.  

I could go on, but I think you get the point.

Here are some suggestions:

Drop the notion of binding altogether.  I think this is really an old
implementation artifact.  Instead, say that every APPLICATION of a lambda
form creates new variables for its formal parameters.  Also, every symbol
has a global variable associated with it.  A variable may have a value, or
it may be valueless.  A variable has an extent and a scope.  

Introduce the function ``assignedp'', which meets the current description of
``boundp''.  ``setq'' changes the value of a variable through
``assignment''.  Lambda application creates a new variable and assigns it a
value. 

(2) Special Form Terminology

A special form is defined as a form beginning with one of the symbols
appearing in Table 5-1.  However, p. 57 states that ``The  set of special
forms is fixed in Common LISP'' and that ``The set of special forms in
Common LISP is purposely kept very small''.  Of course, these claims are
both false.  There are an infinite number of special forms in Common LISP.
What is finite and small is the set of symbols that designate special forms.
These are referred to in Table 5-1 as the ``names'' of special forms.  

Ugh.  I propose the following terminology:  Leave the definition of special
forms alone.  Call the objects referred to by the symbols that designate
special forms ``special functions''.  Call the objects referred to by
symbols that invoke macro definitions ``macro functions''.  Call everything
else a ``normal'' function.  These are the unmarked case, analogous to the
lack of a compelling name for non-``special'' variables.  

This terminology appears to be consistent with ``symbol-function'', which
may return something ``representing a special form (sic) or macro.''