On Feb 16, 2009, at 10:34 AM, Stuart Halloway wrote:
>
> David Sletten sent me this erratum:
>
> <<
> At the beginning of section 2.4 we have "The symbol user/foo refers to
> a var which is bound to the value 10." Under the next subsection
> "Bindings" we have "Vars are bound to names, but there are other kinds
> of bindings as well." The Common Lisp standard defines a binding as
> "an association between a name and that which the name denotes". This
> is the second sense used in the book. The first sense of a "binding"
> between a var and its value is inconsistent.
>>>
>
> Should I be using two different terms, or is the notion of binding
> overloaded?
>
>
Stuart,
I'm sorry but my comments appear to have raised more of a fuss than I
intended. I think I need to clarify two issues:
1. I was probably not sufficiently clear in my intent. I did not mean
so much to point out that you were wrong as to simply highlight the
"inconsistent" use of the words "binding" and "bound". Your term
"overloaded" is more neutral, and therefore a better choice than mine.
In a language such as Common Lisp where every variable is
(effectively) a reference variable, we have three concepts: names,
variables (references), and values (referents). These three things
have two connections. In an orthodox (perhaps pedantic) sense a name
is "bound" to a variable, and the variable "has" a value. Names can
be bound to different variables and variables can be assigned new
values:
(defvar *x* 8) ; Bind "*x*" to special variable and assign value.
(setf *x* 9) ; Assign new value to variable. Binding hasn't changed.
(let ((x 12)) ; Bind "x" to variable, assign value.
(let ((x "pung")) ; Bind "x" to different variable -> different
binding.
(setf x "foo") ; Same (2nd) variable, new value.
...) ; 1st binding visible again outside of inner LET
...) ; No more binding for "x" out here
On a side note, when we talk of scope we shouldn't talk about an
"identifier's scope" or a "variable's scope". Scope is an issue
involving both names and variables: bindings have scope.
The definitions in the CLHS glossary all reflect this interpretation.
However, as I was looking through my notes it became clear that your
overloaded use is hardly idiosyncratic. For example, the CLHS entry
for LET states: "let and let* create new variable bindings and
execute a series of forms that use these bindings." Yet it explicitly
states later that: "...Then all of the variables varj are bound to
the corresponding values". This seems to me inconsistent with the
glossary definitions, but such usage occurs throughout the Standard.
I think that the strict usage is consistent with Clojure's "binding"
macro, which binds a name to a new variable. The "let" special form
does a similar thing, but the situation is a little different than in
CL since you can't assign a new value to a "variable" established by
a Clojure let binding. Consequently, it seems that we can more safely
blur the distinctions among name/variable/value here. A name is
associated with a given value for the lifetime of the binding.
As another example, the language Oz has the notion of identifiers,
which may be either bound or free, and variables, which may either be
bound or unbound. Oz variables are like Clojure lexicals--once
assigned their values cannot change. So an unbound variable is simply
a variable that has not been assigned a value yet. Assignment "binds"
a value to a variable. Likewise, a free identifier is a name that
doesn't refer to anything yet. Once bound, an identifier names a
variable.
So to wrap this all up, if you are satisfied with your discussion in
the book--and you seem justified in that--then I'll just shut up
about binding.
2. My erratum report and comments above should not be viewed as
though I advocate Clojure being evaluated through the lens of Common
Lisp. I have a few years experience studying CL, so naturally that
affects my perception of Clojure. However, in fairness the language
should be judged on its own merits, and I am far too new to Clojure
to make any such judgment yet.
Aloha,
David Sletten
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
