In article <························@c13g2000cwb.googlegroups.com>,
·············@gmail.com" <············@gmail.com> wrote:
> Hi,
>
> (setq x 1)
>
> (let ((x 2)) (defun Y () x))
> (y)
>
> prints 2 in sbcl and 1 in cmucl. which one is right?
>
> David
This is discussed in gory detail in:
http://www.flownet.com/ron/specials.pdf
rg
See the thread "Is there a working open-source lisp implementation?"
from Nov 21, 2004.
BTW, I think all variables made on Jan 1, 1:14 am are special ;)
············@gmail.com <············@gmail.com> wrote:
+---------------
| So, how can I bind a variable in the top-level scope without
| declaring it special?
+---------------
You can't (not portably). Read CLHS "3.1.1.1 The Global Environment",
where it says what the global environment contains. Note that lexical
variables are conspicuously absent.
Several people have addressed this with macros (named variously
DEFLEX or DEFLEXICAL) that use DEFINE-SYMBOL-MACRO to do "indirection"
on what appears to be a top-level binding, while allowing lexical
rebinding in nested scopes... which is really what most people want
from top-level lexicals anyway. E.g.:
> (deflex foo 13)
FOO
> (defun foo-val () foo)
FOO-VAL
> (let ((foo 27))
(list foo (foo-val)))
(27 13)
>
Here's what one implementation [mine] of DEFLEX generates:
> (macroexpand '(deflex foo 13))
(PROGN
(DEFPARAMETER *STORAGE-FOR-DEFLEX-VAR-FOO* 13)
(DEFINE-SYMBOL-MACRO FOO *STORAGE-FOR-DEFLEX-VAR-FOO*))
T
> (macroexpand '(deflex bar 54 "A top-level lexical"))
(PROGN
(DEFPARAMETER *STORAGE-FOR-DEFLEX-VAR-BAR* 54 "A top-level lexical")
(SETF (DOCUMENTATION 'BAR 'VARIABLE) "A top-level lexical")
(DEFINE-SYMBOL-MACRO BAR *STORAGE-FOR-DEFLEX-VAR-BAR*))
T
>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
+ ····@rpw3.org (Rob Warnock):
| Here's what one implementation [mine] of DEFLEX generates:
|
| > (macroexpand '(deflex foo 13))
|
| (PROGN
| (DEFPARAMETER *STORAGE-FOR-DEFLEX-VAR-FOO* 13)
| (DEFINE-SYMBOL-MACRO FOO *STORAGE-FOR-DEFLEX-VAR-FOO*))
Why the extra special? What is wrong with the following?
(define-symbol-macro foo (symbol-value 'foo))
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Harald Hanche-Olsen <······@math.ntnu.no> wrote:
+---------------
| + ····@rpw3.org (Rob Warnock):
| | Here's what one implementation [mine] of DEFLEX generates:
| | > (macroexpand '(deflex foo 13))
| | (PROGN
| | (DEFPARAMETER *STORAGE-FOR-DEFLEX-VAR-FOO* 13)
| | (DEFINE-SYMBOL-MACRO FOO *STORAGE-FOR-DEFLEX-VAR-FOO*))
|
| Why the extra special? What is wrong with the following?
| (define-symbol-macro foo (symbol-value 'foo))
+---------------
That works fine in CMUCL, but for some reason it blew up in CLISP
[at least, back in version 2.29, which was what I had when I was
writing DEFLEX]:
[1]> (define-symbol-macro foo (symbol-value 'foo))
FOO
[2]> (setf foo 17) ; or SETQ, doesn't matter
*** - Lisp stack overflow. RESET
[3]>
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> > (define-symbol-macro foo (symbol-value 'foo))
>
> That works fine in CMUCL, but for some reason it blew up in CLISP
This is fixed in the current CLISP CVS.
Bruno
·············@gmail.com" <············@gmail.com> writes:
>
> So, how can I bind a variable in the top-level scope without declaring
> it special?
In general, you can't.
A non-special binding would have to be lexical, so you would need to
wrap everything in a (LET ...) binding form. Lexical bindings need to
have something to give them their lexical scope.
--
Thomas A. Russ, USC/Information Sciences Institute
············@gmail.com wrote:
> Oh, thanks, I 've re-read the paper and it does give the answer. Many
> thanks.
>
> (locally (declare (special x)) (setq x 1))
Also the standard operators SET and SETF of SYMBOL-FUNCTION could be
used portably. They are briefer to type.
Steven M. Haflich wrote:
> ············@gmail.com wrote:
>
>> Oh, thanks, I 've re-read the paper and it does give the answer. Many
>> thanks.
>>
>> (locally (declare (special x)) (setq x 1))
>
>
> Also the standard operators SET and SETF of SYMBOL-FUNCTION could be
> used portably. They are briefer to type.
I don't follow you, Steven. According to CLHS, SET is deprecated.
Furthermore, how is SYMBOL-FUNCTION relevant here?
David Sletten
David Sletten wrote:
> I don't follow you, Steven. According to CLHS, SET is deprecated.
> Furthermore, how is SYMBOL-FUNCTION relevant here?
SYMBOL-VALUE, he meant.
Paul
Paul F. Dietz wrote:
> David Sletten wrote:
>
>> I don't follow you, Steven. According to CLHS, SET is deprecated.
>> Furthermore, how is SYMBOL-FUNCTION relevant here?
>
>
> SYMBOL-VALUE, he meant.
>
> Paul
But then how is that briefer to type?
(setq x 1) vs. (setf (symbol-value 'x) 1)
David Sletten
David Sletten wrote:
> But then how is that briefer to type?
> (setq x 1) vs. (setf (symbol-value 'x) 1)
That's where the suggestion to use symbol macros comes in.
You can define x to be (symbol-value 'x) using symbol-macrolet.
Paul
Paul F. Dietz wrote:
> David Sletten wrote:
>
>> But then how is that briefer to type?
>> (setq x 1) vs. (setf (symbol-value 'x) 1)
>
>
> That's where the suggestion to use symbol macros comes in.
> You can define x to be (symbol-value 'x) using symbol-macrolet.
>
> Paul
But the OP wanted a top-level variable that wasn't special. CLHS says
explicitly: "symbol-value cannot access the value of a lexical
variable." It also says that "There are three kinds of variables:
lexical variables, dynamic variables, and constant variables." So if
SYMBOL-VALUE cannot access a lexical variable (and we ignore constant
variables here), then it must be accessing a dynamic (special) variable.
David Sletten
David Sletten wrote:
> But the OP wanted a top-level variable that wasn't special. CLHS says
> explicitly: "symbol-value cannot access the value of a lexical
> variable." It also says that "There are three kinds of variables:
> lexical variables, dynamic variables, and constant variables." So if
> SYMBOL-VALUE cannot access a lexical variable (and we ignore constant
> variables here), then it must be accessing a dynamic (special) variable.
Ah, but it's not a special variable. It has never been declared special,
and if you put in another let binding for it, that creates a lexical
binding (one that overrides the symbol macro).
Paul
In article <······················@dls.net>,
"Paul F. Dietz" <·····@dls.net> wrote:
> David Sletten wrote:
>
> > But the OP wanted a top-level variable that wasn't special. CLHS says
> > explicitly: "symbol-value cannot access the value of a lexical
> > variable." It also says that "There are three kinds of variables:
> > lexical variables, dynamic variables, and constant variables." So if
> > SYMBOL-VALUE cannot access a lexical variable (and we ignore constant
> > variables here), then it must be accessing a dynamic (special) variable.
>
> Ah, but it's not a special variable. It has never been declared special,
> and if you put in another let binding for it, that creates a lexical
> binding (one that overrides the symbol macro).
>
> Paul
Still:
(setq foo 'bar) at the toplevel should not declare a new variable
foo special, like it does in CMUCL (last I looked). Even if it may be
allowed by the spec, I still think it is not desirable. Most
other Lisps do it differently.
In article <····························@news-50.dca.giganews.com>,
Rainer Joswig <······@lisp.de> wrote:
> In article <······················@dls.net>,
> "Paul F. Dietz" <·····@dls.net> wrote:
>
> > David Sletten wrote:
> >
> > > But the OP wanted a top-level variable that wasn't special. CLHS says
> > > explicitly: "symbol-value cannot access the value of a lexical
> > > variable." It also says that "There are three kinds of variables:
> > > lexical variables, dynamic variables, and constant variables." So if
> > > SYMBOL-VALUE cannot access a lexical variable (and we ignore constant
> > > variables here), then it must be accessing a dynamic (special) variable.
> >
> > Ah, but it's not a special variable. It has never been declared special,
> > and if you put in another let binding for it, that creates a lexical
> > binding (one that overrides the symbol macro).
> >
> > Paul
>
> Still:
>
> (setq foo 'bar) at the toplevel should not declare a new variable
> foo special, like it does in CMUCL (last I looked).
A strict reading of the standard *requires* this behavior (or requires
an error to be signaled).
> Even if it may be
> allowed by the spec, I still think it is not desirable. Most
> other Lisps do it differently.
Yes, but strictly speaking, any Lisp that does it differently is not
ANSI-compliant. See section 3.1.2.1.1 of the standard.
rg
On Sun, 02 Jan 2005 09:43:31 +0100, Rainer Joswig <······@lisp.de> wrote:
> Still:
>
> (setq foo 'bar) at the toplevel should not declare a new variable
> foo special, like it does in CMUCL (last I looked).
See FAQ #2 and EXT:*TOP-LEVEL-AUTO-DECLARE*:
<http://www.cons.org/cmucl/FAQ.html>
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
············@gmail.com wrote:
> Hi,
>
> (setq x 1)
>
> (let ((x 2)) (defun Y () x))
> (y)
>
> prints 2 in sbcl and 1 in cmucl. which one is right?
>
Both are, in LW
CL-USER 6 > (setq x 1)
1
CL-USER 7 > (let ((x 2)) (defun y () x))
Y
CL-USER 8 > (y)
2
CL-USER 9 > (defvar x 1)
X
CL-USER 10 > (let ((x 2)) (defun y () x))
Y
CL-USER 11 > (y)
1
CL-USER 12 >
The trick here is not to depend on setq. Use defvar.
Wade
Wade Humeniuk <····················@telus.net> writes:
> ············@gmail.com wrote:
>
>> Hi,
>> (setq x 1)
>> (let ((x 2)) (defun Y () x))
>> (y)
>> prints 2 in sbcl and 1 in cmucl. which one is right?
>>
> Both are, in LW
>
> CL-USER 6 > (setq x 1)
> 1
>
> CL-USER 7 > (let ((x 2)) (defun y () x))
> Y
>
> CL-USER 8 > (y)
> 2
>
> CL-USER 9 > (defvar x 1)
> X
>
> CL-USER 10 > (let ((x 2)) (defun y () x))
> Y
>
> CL-USER 11 > (y)
> 1
>
> CL-USER 12 >
>
> The trick here is not to depend on setq. Use defvar.
Or DEFPARAMETER, which behaves slightly more like SETQ in that it
always assigns the given value to the variable, not just when it's
unbound to start with.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp