[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Binding terminology

 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 
    the values-that-have-been-assigned-to-*a*-in-such-a-way-that-they-are-
    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