Could anybody explain the following, I`m a little confused about the
global and local variables, in sbcl the lexical and dynamic scope of
the symbol "a":
> (funcall
(funcall
(defun clos (c)
(let ((a 1))
#'(lambda (d) (princ (list a c d))))) 2) 3)
(1 2 3)
(1 2 3)
> (defparameter a '(fuc))
A
> a
(FUC)
> (funcall
(funcall
(defun clos (c)
(let ((a 1))
#'(lambda (d) (princ (list a c d))))) 2) 3)
((FUC) 2 3)
((FUC) 2 3)
I thought, the body of (let ... will use the assigned (a 1) symbol
value, but this is obviously not so.
Any ideas how I could use the global parameter A and the local A in
the (defun clos ... at the same time?
Thanx a lot.
On Feb 23, 4:56 pm, mosi <·········@gmail.com> wrote:
> Could anybody explain the following, I`m a little confused about the
> global and local variables, in sbcl the lexical and dynamic scope of
> the symbol "a":
>
> > (funcall
>
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
>
> (1 2 3)
> (1 2 3)> (defparameter a '(fuc))
> A
> > a
> (FUC)
> > (funcall
>
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
>
> ((FUC) 2 3)
> ((FUC) 2 3)
>
> Any ideas how I could use the global parameter A and the local A in
> the (defun clos ... at the same time?
> Thanx a lot.
I believe this is nothing more than an order of operations error in
the code.
When the LAMBDA is returned as a closure (the first time), it is in
the LET's lexical environment, where A is bound to 1.
Then you DEFPARAMETER and rebind A making it a special variable
(dynamic). This likely overrides any potential lexical environments
pre-created with that symbol. And, although I'm not a Lisp historian,
I imagine this is one of many reasons why it is considered good
practice to make all special variables named *<symbol>*.
If you did the DEFPARAMETER first, then A would already have been
declared special when the special form LET executes, and your code
would work as expected, returning '(1 2 3). Another option would be to
change the initial code in anticipation of what was going to come.
Since you know A is going to be special, declare it as such:
(let ((a 1))
(declare (special a))
(lambda (d) ...))
Then it will work as you expect it to.
HTH,
Jeff M.
On Feb 23, 11:56 pm, mosi <·········@gmail.com> wrote:
> Any ideas how I could use the global parameter A and the local A in
> the (defun clos ... at the same time?
defparameter creates dynamic variables. When you bind a dynamic
variable using let, the bound value only has an affect on code that is
executed inside the let, not on code that is defined inside the let.
This means that dynamic variables are no use for creating closures
(hence closures in Emacs Lisp are difficult since elisp only has
dynamic scope).
(defparameter *a* nil)
(defun make-a-fn ()
(let ((*a* "This will have no effect!"))
#'(lambda ()
*a*)))
(funcall (make-a-fn))
-> nil
(let ((fn (make-a-fn)))
(let ((*a* "Aha!"))
(funcall fn)))
-> "Aha!"
(let ((*a* "Aha!"))
(funcall fn))
-> "Aha!"
Hence the convention for surrounding special variables with "earmuffs"
- "*parameter*" instead of "parameter".
Regards,
Tom SW
In article
<····································@v38g2000yqb.googlegroups.com>,
mosi <·········@gmail.com> wrote:
> Could anybody explain the following, I`m a little confused about the
> global and local variables, in sbcl the lexical and dynamic scope of
> the symbol "a":
>
> > (funcall
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
>
> (1 2 3)
> (1 2 3)
> > (defparameter a '(fuc))
> A
> > a
> (FUC)
> > (funcall
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
>
> ((FUC) 2 3)
> ((FUC) 2 3)
>
> I thought, the body of (let ... will use the assigned (a 1) symbol
> value, but this is obviously not so.
>
> Any ideas how I could use the global parameter A and the local A in
> the (defun clos ... at the same time?
> Thanx a lot.
Short answer: you can't. To understand why, read
http://www.flownet.com/ron/specials.pdf, and particularly the section
towards the end (I've really got to number those pages) called "The
pervasiveness of DEFVAR." DEFPARAMETER works the same way as DEFVAR.
Long answer: cheat. Create a global dynamic binding for the symbol by
assigning a value to it using SETQ but DON'T DEFVAR (or DEFPARAMETER)
it. Then you can access the lexical binding by simply referencing the
symbol, and the global by calling SYMBOL-VALUE. But this is a Really
Bad Idea (tm). If you find yourself needing to do something like this,
you're almost certainly doing something wrong. Also, not all
implementations will let you get away with this trick.
Long answer #2: Create a global lexical binding for A using a symbol
macro and access its value using EVAL, e.g.:
? (define-symbol-macro a 1)
A
? (let ((a 2)) (lambda () (list a (eval 'a))))
#<COMPILED-LEXICAL-CLOSURE #x300041757E1F>
? (funcall *)
(2 1)
?
The same admonition applies: if you think you need to do this you're
most likely doing something wrong.
rg
Ron Garret <·········@flownet.com> writes:
> Short answer: you can't.
...
> Long answer: cheat. Create a global dynamic binding for the symbol by
> assigning a value to it using SETQ but DON'T DEFVAR (or DEFPARAMETER)
> it. Then you can access the lexical binding by simply referencing the
> symbol, and the global by calling SYMBOL-VALUE. But this is a Really
> Bad Idea (tm). If you find yourself needing to do something like this,
> you're almost certainly doing something wrong. Also, not all
> implementations will let you get away with this trick.
Underscoring Ron's note that it's a really bad idea is the observation
that assigning a value at top-level using SETQ by without the DEFVAR
results in undefined behavior. And there is at least one lisp
implementation that will by default globally proclaim special any such
undefined variable that is assigned a value.
So you really are back to the short answer.
--
Thomas A. Russ, USC/Information Sciences Institute
On 2009-02-24, Ron Garret <·········@flownet.com> wrote:
> Short answer: you can't. To understand why, read
> http://www.flownet.com/ron/specials.pdf, and particularly the section
> towards the end (I've really got to number those pages) called "The
> pervasiveness of DEFVAR." DEFPARAMETER works the same way as DEFVAR.
>
> Long answer: cheat. Create a global dynamic binding for the symbol by
> assigning a value to it using SETQ but DON'T DEFVAR (or DEFPARAMETER)
> it.
> Then you can access the lexical binding by simply referencing the
> symbol, and the global by calling SYMBOL-VALUE.
Why would you advise someone to use SETQ to set up a value, but then
to reference it with SYMBOL-VALUE?
You can fix this cheat by using SYMBOL-VALUE to also create the binding,
since (SYMBOL-VALUE <sym>) is an assignable place.
Whereas SETQ to a symbol that has not been defined as a variable (or a macro
expanding to an assignable place) is undefined, SETF to a symbol's SYMBOL-VALUE
slot is well-defined. The symbol is not required to have been introduced as the
name of a dynamic variable.
On Feb 23, 12:56 pm, mosi <·········@gmail.com> wrote:
> Could anybody explain the following, I`m a little confused about the
> global and local variables, in sbcl the lexical and dynamic scope of
> the symbol "a":
>
> > (funcall
>
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
>
> (1 2 3)
> (1 2 3)> (defparameter a '(fuc))
> A
> > a
> (FUC)
> > (funcall
>
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
>
> ((FUC) 2 3)
> ((FUC) 2 3)
>
> I thought, the body of (let ... will use the assigned (a 1) symbol
> value, but this is obviously not so.
>
> Any ideas how I could use the global parameter A and the local A in
> the (defun clos ... at the same time?
> Thanx a lot.
Wow...You certainly didn't pick the easiest way to explore the issue.
There are actually a couple of things to untangle here. Some of the
problem is SBCL-specific. Some of it is Common Lisp in general.
The first point is that under normal circumstances the names of
function parameters are not really related to symbols with the same
name:
* (defun pung
(qwyxlstyg)
(list (symbol-value 'qwyxlstyg) qwyxlstyg))
Then when you call the function:
* (pung 3)
debugger invoked on a UNBOUND-VARIABLE: The variable QWYXLSTYG is
unbound.
There is no value associated with the symbol QWYXLSTYG even though the
function call assigns the value 3 to the parameter QWYXLSTYG. A symbol
is a kind of Lisp data structure. Usually a parameter is just an
identifier.
There is, however, the "special" case where we create a special
variable:
* (defvar *qwyxlstyg* 12)
*QWYXLSTYG*
* (defun bar () (print *qwyxlstyg*))
BAR
* (defun foo
(*qwyxlstyg*)
(bar)
(list (symbol-value '*qwyxlstyg*) *qwyxlstyg*))
DEFVAR makes the name *QWYXLSTYG* pervasively dynamic, and the value
of the variable is stored in the symbol of the same name. As a result,
a call to FOO doesn't create a separate variable named *QWYXLSTYG*--
instead it creates a local binding for the name. Notice how the
meaning of the name *QWYXLSTYG* inside of BAR depends on the context
in which it is called:
* *qwyxlstyg*
12
* (bar)
12
12
* (foo 3)
3
(3 3)
* (bar)
12
12
* *qwyxlstyg*
12
As you discovered in your experiment, you can't create a closure over
A once you've made it a special variable.
I'm not sure why you are placing a DEFUN inside FUNCALL. You could
simplify your example thus:
* (defun clos (c)
(let ((a 1))
#'(lambda (d) (princ (list a c d)))))
* (funcall (clos 2) 3)
(1 2 3)
(1 2 3)
But here you may run into unexpected behavior:
* (defparameter a '(fuc))
A
* a
(FUC)
* (funcall (clos 2) 3)
(1 2 3)
(1 2 3)
Why is this result different from yours? In fact, SBCL compiles all
code, so that our previously-compiled CLOS function is unaware that A
is now a special variable. However, if we recompile the definition:
* (defun clos (c)
(let ((a 1))
#'(lambda (d) (princ (list a c d)))))
STYLE-WARNING: redefining CLOS in DEFUN
CLOS
* (funcall (clos 2) 3)
((FUC) 2 3)
((FUC) 2 3)
Aloha,
David Sletten
From: Pascal J. Bourguignon
Subject: Re: Lexical and dynamic scope example?
Date:
Message-ID: <87tz6ka9p0.fsf@galatea.local>
mosi <·········@gmail.com> writes:
> Could anybody explain the following, I`m a little confused about the
> global and local variables, in sbcl the lexical and dynamic scope of
> the symbol "a":
The confusion comes from the fact that there are two different things
here:
- whether the variable is global or local.
- whether it has dynamic or lexical scope.
Unfortunately, to confuse the matter even more, CL is not orthogonal
in this respect: it only implements three cases.
dynamic lexical
global defvar,defparameter -
local let (declare special) let (not special)
(Global lexical can be simulated with symbol macros, search for
defglobal in cll).
So global variables are special variables (dynamic binding),
and local variables may be special (dynamic binding) or normal (lexical binding).
>> (funcall
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
>
> (1 2 3)
> (1 2 3)
>> (defparameter a '(fuc))
> A
Implementation dependent code forward.
Since you changed the kind of binding for A, the implementation
doesn't know anymore from the standard what to do with the let ((a 1))
in CLOS. An implementation with an interpreter may choose to switch
to dynamic binding. With a compiler, you may be left with the
interpretation at compilation time.
> Any ideas how I could use the global parameter A and the local A in
> the (defun clos ... at the same time?
Yes. DO NOT!
That's the reason why there's the earmuff convention: put * around the
name of ALL the special variables (both global and local).
(defvar *a* '(not fuc))
(let ((a 1)) (lambda (x) (+ x 1)))
;; no confusion.
(defun f (x)
(declare (special *b*))
(cons x *b*))
(let ((*b* '(ha))) (declare (special *b*)) (lambda (x) (f x)))
--
__Pascal Bourguignon__
mosi <·········@gmail.com> writes:
> Could anybody explain the following, I`m a little confused about the
> global and local variables, in sbcl the lexical and dynamic scope of
> the symbol "a":
>
> > (funcall
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
Well, adding a bit to the confusion is also the use of the DEFUN macro
inside of the FUNCALL function call. Since the purpose of DEFUN is to
provide a global binding of the function value of some symbol, you
really don't want to use it nested inside code.
It is a bit disorienting to Common Lisp readers to suddenly encounter
global function definitions deeply nested inside other code. The only
reason this even works is because defun returns a symbol which just
happens to have been assigned a function value.
Clearer would be to pull the DEFUN out of that code. It would also make
it a lot easier to see the assignment of values to variables in the
chain of values:
(defun clos (c)
(let ((a 1))
#'(lambda (d) (princ (list a c d)))))
(funcall (funcall 'clos 2) 3)
> (1 2 3)
> (1 2 3)
> > (defparameter a '(fuc))
> A
> > a
> (FUC)
> > (funcall
> (funcall
> (defun clos (c)
> (let ((a 1))
> #'(lambda (d) (princ (list a c d))))) 2) 3)
>
> ((FUC) 2 3)
> ((FUC) 2 3)
>
> I thought, the body of (let ... will use the assigned (a 1) symbol
> value, but this is obviously not so.
Nope. Because you have changed the nature of the variable from lexical
to dynamic. So it will pick up the dynamic value of the variable.
> Any ideas how I could use the global parameter A and the local A in
> the (defun clos ... at the same time?
You can't. The whole point of having a dynamic binding is that you get
the dynamic binding behavior that you are seeing here. It is also the
globally pervasive nature of this that makes it important to try to
avoid name collisions -- thus the *...* convention for naming special
variables.
Now, if you don't need a GLOBALLY special variable, you can mix dynamic
and lexical bindings with the same name:
(defun other ()
(let ((a 3))
(list a (locally (declare (special a)) a))))
(let ((a 1))
(declare (special a))
(other))
But I wouldn't recommend it. The naming conventions for special
variables exist to try to remove the potential for just such
confusions.
--
Thomas A. Russ, USC/Information Sciences Institute