BTW, thanks for your second follow-up post clarifying some points you
brought up in your first post, all that helps considerably in getting
me to understand the various subtle aspects of this issue.

Give me a little time to let this all sink in.

So, after (define-symbol-macro x (list 1 2 3)),
there is no difference at all between (eql x x)
and (eql (list 1 2 3) (list 1 2 3)). And LIST
is guaranteed to cons up a fresh list each time
you call it.

This NG is great.  The people here bring out points about CL that are
not at all apparent from reading CL books!

What (list ...) returns is the address in memory of a freshly-consed
Lisp list. This is known as "returning a list". As a previous poster
said, (list ...) always conses up a fresh list. (The objects contained
in the list needn't be fresh but the conses in the list are fresh; the
fresh conses can point to old, previously-existing objects.) A Lisp list
is a series of cons cells with the car of the cons containing the list
entry and the cdr of the cons pointing to the next cons in the list.
That's why a and c are "the same" below. Both a and c are variables
bound to the same cons cell, which is the first one in the list. (Note:
I never hear Lisp people talk about "point to". a is not a variable, it
is a symbol. It may be correct to say the symbol is bound to the list.
If that is not a correct phrasing, I expect quickly to be corrected.)

But there's a misuse in my code. I'm using eq, not eql. a and c always
will be eq - the object referred to is the same both for a and c. Think
of eq as comparing memory addresses, that is, eq asks if the two
parameters reside at the same memory address. (Implementations are
allowed to treat chars and numbers differently with eq. See below for
more.) Although in this example the (car a) or (car b) comparisons show
eq returning T, and many implementations may do so, that is not a
requirement. It's worse than that. It's back to the undefined behavior
discussions you've been through recently.

Look at eq in the hyperspec. eq may or may not return T when given "the
same" haracters and numbers. I included eq's here just to let you know
that you should use eq when comparing things like a and c, eql when
comparing numbers and characters, equal when comparing larger structures
such as lists (conses) or arrays (strings and bit-vectors are compared
element by element using eql). equalp is like equal except ignoring
case.  eq may appear to work when comparing characters and numbers but
it is not guaranteed to work for that purpose.

It's easiest for beginners to use eql except when comparing strings,
when it is good to use equal (or equalp for case insensitivity). (I
think I have that part right.)

(By the way, in the Lisp implementation I'm using, the following code
gave the same result when I used eql instead of eq.)

CL-USER 18 > (let* ((a (list 1 2 3))
                     (b (list 1 2 3))
                     (c a))
                (format t "~&1: ~a ~a eq?:~a" a b (eq a b))
                (format t "~&2: ~a ~a eq?:~a" (car a) (car b)
                                               (eq (car a) (car b)))

                (format t "~&3: ~a ~a eq?:~a" a c (eq a c))
                (rplaca a 4) ;; replace the car of 'a' with '4'
                (format t "~&4: ~a ~a eq?:~a" a b (eq a b))
                (format t "~&5: ~a ~a eq?:~a" (car a) (car b)
                                               (eq (car a) (car b)))
                (format t "~&6: ~a ~a eq?:~a" a c (eq a c)))

1: (1 2 3) (1 2 3) eq?:NIL
2: 1 1 eq?:T
3: (1 2 3) (1 2 3) eq?:T
4: (4 2 3) (1 2 3) eq?:NIL
5: 4 1 eq?:NIL
6: (4 2 3) (4 2 3) eq?:T
NIL

CL-USER 19 >

In the example below, x is a define-symbol-macro, which means that x is
replaced by (list 1 2 3) wherever x appears.  x appears twice in (eql x
x).  Therefore it is the same as (eql (list 1 2 3) (list 1 2 3)), which
is the same as a and b in my example above.  Each invocation of list
created a fresh set of conses, the addresses in memory of which are
different. (eql x x) ==> NIL means that the two lists are not the same
list, the leading cons cells are not at the same memory address.
Compare that to my example #3 above, where a and c are the same list and
(eql a c) ==> T. a and c are symbols bound to the same variable, the
same cons cell, the same address in memory.

I tend to use equal for everything unless I want the added code documentary
benefits of = (means this is math), string= -equal or -equalp (means we are
using only strings), eq (means I am using symbols) and char= (means I know
these are characters)

Whenever things might be mixed and I don;t want an error (most often NIL can
slip in) it's back to EQUAL.  (YMMV, IMHO, etc etc...)

*** - BOUNDP: 2 is not a symbol

Funny ;)

--
Ivan Boldyrev

  [1]> (let ((x 2)) (boundp x))

  *** - BOUNDP: 2 is not a symbol

Next, BOUNDP, being an ordinary function, doesn't know about lexical
bindings:

  [2]> (let ((x 2)) (boundp 'x))
  NIL

Finally, clisp's BOUNDP (or perhaps DEFINE-SYMBOL-MACRO) seems to be
broken:

  [3]> (define-symbol-macro x 2)
  X
  [4]> (boundp 'x)
  T

CL-USER 11 > (equal '(a b c) '(a b c))
T

CL-USER 12 > (equal #(a b c) #(a b c))
NIL

to them, if you had told them just before that EQUAL was the generic
equality predicate?

Object identity is a fundamental notion; equality is not.

Regards,
--
Nils Gösche
"Don't ask for whom the <CTRL-G> tolls."

The important thing about whether something is a closure or not is
whether it preserves the prior state (value) of a variable when a
lexical binding form like a "let" is trying to change that value.

Consider code below, where this time it is called test2 instead of test.

Forgive the sloppy code, I don't know how to use "format" yet.

(define-symbol-macro x 2)

(defun test2 ()
   (terpri)
   (princ "\"test2\" is a closure because it preserves value of global
x\,")
   (terpri)
   (princ "value of global x in this case is ") (princ x)
   (terpri))

(let ((y 3))
 (defun test3 ()
    (terpri)
    (princ "\"test3\" is also a closure\, made in the conventional
way\,")
    (terpri)
    (princ "it preserves the value of ") (princ y)
    (terpri)))

(defun test4 (p)
    (terpri)
    (princ "\"test4\" is not a closure\, it preserves no prior value\,")
    (terpri)
    (princ "this time test4 prints ") (princ p)
    (terpri))

(let ((x 'boom) (y 'bam) (z 'fizzle))
    x y
   (terpri)
   (test2)
   (terpri)
   (test3)
   (terpri)
   (test4 z)
   (terpri)
   (terpri)
   (terpri)
   (values))

Below is the screen printout from running the "let" form:

"test2" is a closure because it preserves value of global x,
value of global x in this case is 2

"test3" is also a closure, made in the conventional way,
it preserves the value of 3

"test4" is not a closure, it preserves no value,
this time test4 prints FIZZLE

Is relying on "define-symbol-macro" going to get me into trouble down
the road, in your estimation.

You *really* need to go away and do some serious reading, because you
are making yourself look (no: you have made yourself look) a fool.

  (define-symbol-macro x 2)

and then this:

  (defun x () 10)

Lisp doesn't get confused when you say this:

  (x) ==> 10

while:

   x ==> 2

and

   '(x) ==> (x)

That is, the macro is not expanded in contexts where it doesn't "look
like" a variable. (As opposed to, say, C "macros" which really are
textual substitution. Blech.)

When you are an expert, you may figure out some clever hacks that you
can build on top of symbol macros, but until then you mostly seem to
be confusing yourself.

You really ought to consider starting back from the top--what's the
problem you're trying to solve? I.e. if you're trying to write some
software, what's it supposed to do? I imagine there are some folks
here might be willing to help you figure out the idiomatic Lisp way of
writing software that does whatever it is.

-Peter

--
Peter Seibel                                      pe...@javamonkey.com

(defun foo (x)
  (+ x 3))

Is this closed over anything?  What if I told you that I was mentally
thinking of a variable name, but I knew it would never change from 3,
so I omitted it and just used the literal.  Under your definition, FOO
is closed over a variable, but you'd have to read my mind to find out
which variable.

(defun foo (x)
  (values
    (lambda () (incf x))
    (eval `(LAMBDA () ,x))))

[Mark again:]

But: Until you understand what define-symbol-macro is
doing, using it is liable to get you into trouble;
until you understand how variable bindings work in
Lisp, just about everything is going to get you into
trouble.

But the solution to this is to learn to understand,
not to put define-symbol-macro in a box labelled
"dangerous". Everything's dangerous until you
understand it.

On the other hand, if you weren't determined that
your first Lisp project *must* involve Paul Graham's
continuation stuff, I'd suggest that you could pick
better areas of Lisp to concentrate on for now...

However, I maintain that a closure can "close-over" and preserve the
value of "stuff" other than the bindings created by 'let' and its
cousins.

Let's look at the temporary binding of x to the value 7 below:

(defun baz (x)
"The parameter-variable x is 'bound' temporarily to
   whatever value is supplied to baz when baz is executed"
  (cons x  '(is bound to x within the function baz)))

Now when baz is used below, the value 7 is temporarily "bound-to" the
lexically-scoped variable x which resides in the definition of the
function baz.

? (baz 7)
(7 IS BOUND TO X WITHIN THE FUNCTION BAZ)

baz does not qualify as a closure bacause the binding of x is not
preserved; that binding of x to value 7 is lost as soon as baz
terminates.

Okay, with that out of the way, let's create two things, a real closure
which we will name "closure", and a function that might be a closure,
which we will name "closure???"

The aim of this exercise is to determine if both functions act the same
under all circumstances of usage.

(define-symbol-macro  k  'whoopie)

(defun  closure??? ()  k)

(let ((h  'fe-fi-fo-fum))
   (defun closure ()  h))

Now if "closure???" looks like a duck, sounds like a duck, and waddles
like a duck, as far as I am concerned it is a duck.

? (let ((k  'newer-value-of-k)  (h  'newer-value-of-h))
     (print k)
     (print h)
     (closure))

NEWER-VALUE-OF-K
NEWER-VALUE-OF-H
FE-FI-FO-FUM

? (let ((k  'newer-value-of-k)  (h  'newer-value-of-h))
     (print k)
     (print h)
     (closure???))

NEWER-VALUE-OF-K
NEWER-VALUE-OF-H
WHOOPIE

So far, both "closure" and "closure???"  both act alike, in the sense
that they both preserve the values of whatever they were bound to at
the time of their creation.

Yes, I accept the fact that k is not a variable, but rather a macro.

Despite that, to all intents and purposes k acts like a variable, does
it not?

I imagine that if I pushed it too far, k would break my code just when
I started relying on k to act like a variable.

In other words, there are things that can only be learned by asking
specific questions in NG's like this one.

In order to do that, I have to learn enough about scope and extent
issues peculiar to his macros.

The text and examples in his book do not go into sufficient detail
about toplevel bindings and extent issues of his global variable
"*cont*" in his book.

Specifically, my present 'learning-project' is to try to implement
catch/throw using continuations only, i.e. to pretend that catch and
throw do not exist in CL.

I care less about appearing a fool, that does not bother me at all.

If I make foolish, wrong, convoluted, nonsense statements in this NG,
the fine people here do not let those statements stand.

They correct me, and I learn.

...then I make another rash statement, based on my enlightened newer
knowledge.  If the newer statement is still incorrect, again I get
corrected forthwith.

As I get closer and closer to the truth of the matter, eventually my
statements make sense.

(I'm not as convinced as some people here that it's
a very bad way to learn. There's something to be said
for jumping in at the deep end, and there's a lot to
be said for learning by doing something that motivates
you. But you have to be aware that you're running the
risk of annoying the people you depend on for help
so much that they give up...)

Several of your comments have demonstrated a general lack of rigor
required to grasp the underlying issues. You have also on numerous
occasions referred to "On Lisp", which could be considered an advanced
text. Hence, I would recommend two books to you:

1)  Structure and Interpretation of Computer Programs. The full text is
available online, just google for it. Don't just read it, but do the
excercises as well. And don't expect to finish it in "a week or
two". Depending on the time you invest two months to a year is a more
realistic goal.

After you have finished the SICP:

2) ANSI Common Lisp by Paul Graham. This one you have to buy, but it's
worth it. If you have SICP under your belt at this point it will be fast
and easy reading.

Then you can have a go at "On Lisp" and continuations. Sorry, but that's
the way it is.

Cheers,

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

(x)
(set-x 3)
(x)

Hey, look, mutable state!

As to your claim that `there are things that can only be learned by
asking specific questions in NG's like this one': if you type `lisp
closure' at google the *first* hit you get is David Lamkins' excellent
`successful lisp' book.  Was it too hard to do that?

The pattern is this.

Someone comes to Common Lisp.  "Good language," he says, "but I don't
like `X'.  Why isn't `X' the way it is in C#, or Scheme, or Intercal?"

"Because of ZZ," replies the Lisp community represented on
comp.lang.lisp.

"But I don't agree with ZZ."

"Well, maybe you will once you've learned a little more about how Lisp
works."

"Not a chance.  Tell you what.  Lisp is supposed to be mutable, right?
Well, I'll make it the way I want!  That's it!  I'll make it have
brackets instead of parentheses, or continuations instead of catch and
throw, or whatever.  Oh, by the way, the Lisp standard is broken,
backquote doesn't work the way the standard says.  And closures aren't
what you think they are, and...."

The next thing you know, there are black helicopters overhead and you
are being detained for questioning by the masses.

I take it you do have your personal affairs in order?

(For the humor impaired, the above is ENTIRELY tongue-in-cheek!)