Common LISP terminology

[wilensky%ucbdali@Berkeley (Robert Wilensky)]

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:

(1) 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) Preserve the notion of a binding as the association of a variable and a
value.  We still say that every APPLICATION of a lambda form creates new
variables for its formal parameters.  But we can now consistently say that a
variable is bound, meaning that it has a binding, meaning that it is
currently associated with a value.  Leave ``boundp'' as is.  Parameter
variables, special variables and global variables can all be ``bound'' to
values.

(3) Introduce some more terminology.  First, state that all variables have
``bindings'', i. e., instances of variables.  This includes a global binding
for the global variable named by each symbol.  Different applications of a
lambda refer to different bindings of the same variable (if you must).  All
variables are always ``bound'', unless perhaps you introduce some new
construct that really and abnormally removes bindings.  In addition,
bindings, and only bindings, which are the only repositories for values, can
be ``assigned'' values.  ``assignedp'' does what ``boundp'' now does.

Note that if you define ``binding'' as a variable instance, i. e., an
object, rather than as an association of a variable (or variable instance)
with a symbol (or with a value!), then we are in need of terms to describe
(1) the relation of a symbol to a variable, (2) the relation of a variable
to its binding(s), and (3) relation of a binding to a value.  The first
seems to be the ``naming'' or ``named by'' relation; the second may be
called ``instantiation'',  or some such, and the third could be called
``assignment.''

Personally, I prefer (1).  It is simplest and least confusing.  The
terminology of shadowing can still apply to give a lucid description of the
rules of reference.  Also, it seems to be most compatible with the notion of
generalized variables.

(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 macrq 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.''