[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Binding terminology
- To: DLW@alderaan.scrc.symbolics.com, Miller.PA@xerox.com, Moon@stony-brook.scrc.symbolics.com, Pavel.firstname.lastname@example.org
- Subject: Re: Binding terminology
- From: hilfingr%tully.Berkeley.EDU@BERKELEY.EDU (Paul Hilfinger)
- Date: Thu, 5 Feb 87 16:24:42 PST
- Cc: Common-Lisp@sail.stanford.edu
Daniel Weinreb writes:
"Now, consider the following question: `The body of x is a function-call
form that adds two variables. The first variable is a lexical variable
named x. Which variable is the second variable referenced by x?"
I believe that this question has a single, clear answer. [*a*] always
refers to one particular variable, and it's that variable.
The alternative view is to say that ...
it depends on who is calling foo, and what the environment is
at the time.... Simply looking at foo does not tell
you what variable foo is talking about. In order to explain Lisp this
way, you need to introduce some kind of new concept called an
"identifier" ... that is separate from the concept of a
"variable", and say that the association from a given identifier to a
given variable depends, in some cases, on what conditions prevail at
Such a philosophy seems pointless. Having gotten "rid" of dyanamic
binding of variables to values, you have replaced it with a new concept
of identifiers, and a dynamic binding of "identifiers" to "variables".
No complexity has been removed, and a new fundmental concept has been
added, resulting in a new gain in complexity for no benefit.
This is a really good try at standing the situation on its head, but it
doesn't quite make it.
(1) Having been told that *a* always means the same variable (and having
then discovered what that really means) the questioner's response
would then be, "Oh, I meant to ask something else, then: which of
currently-available-or-might-be-restored-later does *a* have?" (The
long, hyphenated construct is used to avoid introducing a new concept,
which some call "binding", since this description of Lisp is not
supposed to require introducing a new concept beyond "variable.")
To put this all less cutely: TANSTAAFL; if there is only one variable,
there have to be several of something else. The number of concepts
is NOT reduced by there being just one variable.
(2) The "identifier" argument is a bit weak, since Lisp already has a
concept of "symbol," which will serve for all but pedants.
(3) The argument concerning future extensions for parallelism is, in
my mind, a good one. If the same symbol, when not lexically bound
always refers to the same "variable" and if the properties of that
variable (e.g., its value) do not depend on the environment (but
instead are changed by certain program constructs, including setq
and let), then you'll have a little difficulty explaining how the
same dynamically bound variable (i.e., referenced by the same
symbol) can have two different values when simultaneously read by
two concurrent processes (and, yes, you certainly DO want to be
able to have two concurrent processes simultaneously providing two
lambda bindings for the same--in CLtL and Weinreb's