I can see be the general tone of the responses lately that I have worn
out my welcome here.

Thanks to all here for helping me learn, I appreciated it immensely.

I would have liked to continue, but that does not seem possible because
my preferred method of learning tends to infuriate people here.

I noted that there was one side thread where the poster wrote that he
gained valuable insite from the posts in  _this_  thread, so I feel
somewhat vindicated by my "fool's-approach" to acquiring knowledge.

Cool down fellas, and remember:

Old CL newbie fools never die, they just   f-a-a-a-d-e   away.

Thanks to the unknown poster who contributed code below:
*********************************************

(let ((x 1))
  (defun x () x)
  (defun set-x (new)
    (setf x new)))
*********************************************

Running his code in MCL ver' 4.3
? (x)
1
? (set-x 3)
3
? (x)
3
?

At the very least, this is unexpected behavior.  It is yet another
exception to the general behavior of CL that has to be memorized and
allowed for so it won't bite me later.

Lisp gurus somehow learn the exceptions to general rules, (as those
rules are laid down in the books), but the only way I had to learn
about the nasty behavior above was to make a rash statement about how I
thought the cookie crumbled, then sit back and wait for agreement or
disagreement to my rash statement.

At the worst, something is broken somewhere in the CL implementation or
in the CL hyperspec, and should be changed.

Contrast that posters example with my variation below which runs as it
should run.

(defvar a)
(defvar b)

(let ((x 'value-of-lexical-x) (y 'value-of-lexical-y))
    (setq a x)
    (setq b y)
    (setq x 'screwed-up-value-of-lexical-x)
    (setq y 'screwed-up-value-of-lexical-y)
    (values))

? a
VALUE-OF-LEXICAL-X

? b
VALUE-OF-LEXICAL-Y

Now let's make small changes in my above code to demonstrate the
unexpected nasty behavior, nasty behavior that is  *not*  explained in
any of the books that have been recommended to me in this NG.

(defvar a)
(defvar b)

(let ((x 'value-of-lexical-x) (y 'value-of-lexical-y))
    (setq a  #'(lambda () x))
    (setq b  #'(lambda () y))
    (setq x 'screwed-up-value-of-lexical-x)
    (setq y 'screwed-up-value-of-lexical-y)
    (values))

? (funcall a)
SCREWED-UP-VALUE-OF-LEXICAL-X

? (funcall b)
SCREWED-UP-VALUE-OF-LEXICAL-Y

I don't want to "piss people off" so this will likely be my last post
in this NG.

I can see now why there are so few new newbies adopting CL as their
preferred language, when it is apparent how cantankerous and downright
ornery people are in this NG.

Cheers,

I must admit to being rather confused now though.  At some point
earlier in the thread you were enthusing about wanting to do
everything with continuations and complaining that it was a deficiency
that CL didn't have call/cc.

Well, one fairly common view of continuations (and, I expect, how they
would appear in a CL which did have them), is that they are simply the
generalisation of closures to include block names and possibly other
control points, which currently have lexical scope and dynamic extent,
to have lexical scope and indefinite extent.

How can you want call/cc and *not* understand what a lexical closure
is?  Do you actually have any *idea* what a continuation is, or are
you just repeating some magic phrase that you read?

Incidentally I liked this:

I'm not asking just out of curiosity, by the way.
I'd like to explain, but I don't see how to explain
until I know what it is that needs explaining. Maybe
this potted summary will help in the interim:

It's common to say that (1) a closure is a function
plus its environment, and (2) an environment is a
mapping from names to values. In fact, I've said
both those things several times myself. But #2 may
be misleading, because an environment is a *changeable*
mapping from names to values. It might be better to
call it a mapping from names to *value-holders*, or,
more simply, to variables. So, when you say

    (let ((x 'value-of-lexical-x) (y 'value-of-lexical-y))
      ...)

you have created new variables X and Y. They're visible
only within the scope of the LET (unless X or Y has been
declared special, of course). But they're real variables,
and they continue to exist after the LET form has finished
being processed.

Now, the things you've put into A and B inside the LET
form are closures: each is a function plus (a reference
to) its environment. That environment consists of the
bindings of X and Y. Note: the *bindings*, not the
*values*. If you change what X and Y are bound to,
that change is visible to the closures in A and B.

Which is exactly what happens when you do the third
and fourth SETQs. The closures in A and B still refer
to the same variables X and Y, but now the values of
those variables have changed.

You obviously find this nasty, but I don't know why.
Here's an example of somewhere where it might be
useful. The MAPHASH function calls a user-supplied
function for each (key, value) pair in a hash table.
So you can do things like this:

    (let ((boring-keys nil))
      (maphash (lambda (k v)
                 (when (null v)
                   (push k boring-keys)))
               *my-hash-table*)
      (format t "~&Boring keys:~{ ~A~^,~}." boring-keys)
      (do-something-else-with boring-keys))

Notice that what you're passing into MAPHASH is a closure
that needs to be able to alter BORING-KEYS.

As it happens, you can do that without closures with
either LOOP or WITH-HASH-TABLE-ITERATOR. So here's another
example. Suppose you're doing some kind of mathematical
computing; numerical integration, perhaps. You have a
bunch of algorithms you've been developing for adaptive
quadrature (i.e., calculating integrals to a prescribed
level of accuracy, working out what function evaluations
they need to do to achieve that accuracy) and you want
to see how they compare. Then:

  - You can count the number of times one of the algorithms
    evaluates the function, like this:

        (defun count-evaluations (integrator integrand)
          (let ((n 0))
            (funcall integrator (lambda (x) (incf n) (funcall integrand x))
                                *lower-bound* *upper-bound*)
            n))

  - You can get a list of the arguments at which it evaluates
    the function, like this:

        (defun evaluation-points (integrator integrand)
          (let ((result '()))
            (funcall integrator (lambda (x)
                                  (push x result)
                                  (funcall integrand x))
                                *lower-bound* *upper-bound*)
            result))

  - You can count the number of times it does two successive
    evaluations very close together, like this:

        (defun count-near-repetitions (integrator integrand)
          (let ((n 0)
                (last nil))
            (funcall integrator (lambda (x)
                                  (when (and last (<= (abs (- x last)) *delta*))
                                    (incf n))
                                  (setq last x)
                                  (f x))
                                *lower-bound* *upper-bound*)
            n))

All this without having to make any change to the code
of the integrators or the integrand functions. And this
*requires* the ability to alter variables you've closed
over. You call that "nasty", but it isn't nasty; it's
at least half of the point.

Backing up a little, Mark wrote:

But it isn't an exception to the general behavior.  It is a new idea.
It goes along with Lisp.  This is how closures work.  It's not nasty
behavior.  It's wonderful.  It's part of the underlying stratum of
object-oriented programming.

If you like continuations how can you not like this?

Most people in this newsgroup have at least a bit of the language
evangelist in them, and if you stay good humored you can probably do
fine.  There is kind of an expectation that eventually you'll graduate
beyond newbie-hood, but I'm sure you haven't worn out your welcome
yet.  Honestly, even if you post things people think are nonsense you
will always find those ready to rise up in anger to smite you, and you
could even glean information from that.

********************************
What you demonstrate IS the general and expected behavior.  You do not
understand anything about how closures work in Common Lisp.  Stop telling us
that we are wrong and learn how they actually do work.

How is it that everyone else seems to understand these concepts?  Have you even
begun to think that maybe... just maybe... you are doing something wrong?  And
this has nothing to do with learning methods, this has to do with LISTENING and
UNDERSTANDING what people say.  Your learning level is on par with a 3-year
old, right now.  
********************************

Let me illustrate this for you better:

The functions X and SET-X share a single BINDING.

Let us repeat that:

The functions X and SET-X share a single BINDING.

Do you notice the word BINDING?

BINDING BINDING BINDING BINDING BINDING (5 times, hopefully enough)

That BINDING is named by the variable X.

X is BOUND to 1, initially.

X  ----->  1

Calling (X) returns the value of evaluating that variable binding, giving you
1.

Calling (SET-X 2) modifies the binding of X so that it now is BOUND to 2.

X  ----->  2

Now, calling (X) returns the value of evaluating the variable binding named X.
Can you guess what happens?

I better spell it out: it returns 2.

Stop futzing with continuations, and get your easy semantics down pat first.
You are trying to do calculus without being able to add, much less anything
else.

--

Now why can't everyone in this NG be as non-judgemental as you are.

Very fine post you crafted, gentle nudges and suggestions, makes me
actually enjoy learning this CL stuff.

Up until Gareth's post, I used to think both these terms meant the same
thing.

   "The binding of x is 5"

   "The value of x is 5"

I completely missed the distinctions between the terms while reading
about closures in my books, and the connection between the words
"binding" and "environment", which proved to be my downfall and led to
me making foolish statements about how the cookie crumbled.

Gareth came to my rescue, explaining that "binding" and "value" are two
seperate and completely different things.

Once I was alerted to that, everything else fell into place.

Before today I could not spell "expert".

Now I are an expert on closures  ;-)

Anyhow, at least now I know a little bit more about them.

About the difference between 'binding' and 'value' -
    In retrospect, I can't believe I was blind-sided by such an obvious
ommission from my store of knowledge.

Wonder what else I have screwy ideas about.

Hmm, time for me to make more rash statements about how I believe the
cookie crumbles.

Wait fellas, wait - I was just kidding.

Oh, I read the prattle in the books about bindings, then more prattle
about values, but  _nothing_  in those books about a binding being
different than a value.

Up until now, I thought that saying "the value of x is 5" was exactly
the same as saying "the binding of x is 5".

Thanks to your post, I now realize that "binding" and "value" are two
seperate and distinct things.

After reading your post, I did some experimenting:

? (let (x) (setq x 5) x)
5

The (x) in the let-form above creates a "binding" for x.
(whatever the heck a "binding" is)

The  (setq x 5)  creates a "value" for x.

To elaborate a bit, let's make a slightly more complicated 'let'

? (let (x  (y  7))  (setq x 5) (list x y))
(5 7)

The (let (x...   in the let-form above creates a "binding" for x.
(whatever the heck a "binding" is)

The  (setq x 5)  creates a "value" for x, a separate operation from
creating the "binding" for x.

The  (y 7)  creates a binding  *and*  a value for y.

Now, thanks to you, and no thanks to the %*#&*!  books, I *finally*
have a clear idea of what a "closure" is.

Back to the book, I gotta find find out what earthly reason there is
for seperating "binding" from "value", other than to confuse newbies.

Needless to say, your post gets saved to my Extremely-Valuable-Posts
file.

I think if you spend 6 months really trying to learn Common Lisp, by
writing programs, then you'll find yourself starting to write Lisp in
other languages too.  I didn't really start to perceive some of the
subtlties of C/C++ (such as they are) until I began a serious approach
to Common Lisp.

here, `let' creates a small telescope (we are one end, `x' the other),
`setq' moves the telescope.  the 5 has always been there (how could it
not be?); moving the telescope in its direction does not create it.
what is created is our awareness of it, through the `x'.

that is why "the truth is out there" is not a bad approach to
mass-market functional conspiracy programming...  (end lame joke).

binding n. an association between a name and that which the name
denotes. ``A lexical binding is a lexical association between a name and
its value.'' When the term binding is qualified by the name of a
namespace , such as ``variable'' or ``function,'' it restricts the
binding to the indicated namespace, as in: `` let establishes variable
bindings.'' or `` let establishes bindings of variables.''

There are goods books for beginners out there, some for free, that
explain theses things. For example, take a look at http://psg.com/~dlamkins/sl/cover.html

And I thought there was much more that "binding" meant, that influenced
exactly how the variable would act in a program.

Now I see why the great majority of my Lisp books don't even mention
"binding" in the index.

Okay, if I FINALLY understand binding correctly, the 'let' form below
does *not* establish a binding between x and anything else!

? (let (x) x    'lexical-variable-x-is-not-bound-to-anything)
LEXICAL-VARIABLE-X-IS-NOT-BOUND-TO-ANYTHING

Likewise:
    (defvar k)

The special variable k is not bound to anything either.

All the lousy defvar does is make a promise to the compiler, a
'declaration' to the compiler, (and to anyone who reads my code), that
eventually a 'special' binding to k  _will_  be created, if and when I
get around to using setq to create the binding.

Likewise:
   When one uses the word "binding" when describing closures -

...as in "In the closure k below, lexical variable x is bound to the
value BIG, and lexical variable y is bound to the value DADDY"

I am right back where I started a week ago, when I said there was no
difference between saying:

     " X is 'bound' to the value BIG "

             - - or - -

       " The value of  X is BIG "

Okay, here is the closure k that I have been talking about:

(defvar k)

(let ((x  'big) (y  'daddy))
    (setq k  #'(lambda () (list x y) )))

? (funcall k)
(BIG DADDY)

Now, where is that guy who made a statement a few days ago to the
effect that a closure preserves the bindings, not the values.

To me they seem to be essentially the same thing.

Wonder what he meant?

Oh well, twenty years from now I will figure it all out.

FWIW,  all SICP had about bindings was a general statement on page 184
that bindings associated values with variables.

Mark Conrad wrote this to Gareth McCaughan:

       "The lexical binding of x is 5"

       "The value of x is 5"

..."binding" could get across a little more information, like whether
the variable x is lexically-scoped or dynamically-scoped.

I have a bunch of good Lisp books, but they don't go into detail about
whether or not there are any more differences between "binding" and
"value".

(defvar k)
(defvar setx)
(defvar sety)

(let ((x 'big) (y 'daddy))
  (setq k #'(lambda () (list x y)))
  (setq setx #'(lambda (value) (setq x value)))
  (setq sety #'(lambda (value) (setq y value))))

? (funcall k)
(big daddy)

? (funcall sety 'mummy)
mummy

Try to guess what (funcall k) will print now.

And PLEASE: It's not very constructive that you don't follow the links
people provide to you. See http://www.psg.com/~dlamkins/sl/contents.html, especially lessons 5 and 6.

Do it! Do it now! Take some time to read and understand these things.
There are over 30 chapters in that book. You don't want to post that
much as you do on every single topic, right?

In this section the withdraw is a closure.

[note: (define (withdraw amount) ...) is sugar for
        (define withdraw (lambda (amount) ...)) ]

<http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-20.html>

The pedagogy of the book is to show you how things work first,
and then later in great detail explain the evaluation model.