Hello, All!
there's an example in CLHS:
(setf (symbol-value 'x) 6)
(defun foo (x) ;a lexical binding of x
(print x)
(let ((x (1+ x))) ;a special binding of x
(declare (special x)) ;and a lexical reference
(bar))
(1+ x))
(defun bar ()
(print (locally (declare (special x))
x)))
(foo 10)
>> 10
>> 11
=> 11
in clisp 2.33.1 it is
10
7
11
in other implementations (acl and lispworks) output is same as in CLHS. so
clisp is wrong?
as i understand question is if special declaration is applied to expression
in let. in this CLHS example it's not applied, in clisp it is. is it
explicitly specified in CLHS?
With best regards, Alex 'killer_storm' Mizrahi.
Alex Mizrahi <········@hotmail.com> wrote:
+---------------
| there's an example in CLHS:
+---------------
The examples in CLHS are not normative, that is, they don't *define*
the standard, only comment about it. Sometimes the examples have bugs
in them. That's the case here.
+---------------
| (setf (symbol-value 'x) 6)
+---------------
There is no defined behavior in the absence of a global definition
of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
the SETF with a DEFVAR, then CLISP gives the same result as the others.
+---------------
| (defun foo (x) ;a lexical binding of x
+---------------
But it's not lexical if there is a global special declaration.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> +---------------
> | (setf (symbol-value 'x) 6)
> +---------------
>
> There is no defined behavior in the absence of a global definition
> of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
> the SETF with a DEFVAR, then CLISP gives the same result as the others.
I've seen statements like this before, but I can't think of anything
in the spec that supports such a statement. Certainly, I don't see
anything on the SYMBOL-VALUE page. Am I forgetting something obvious
somewhere else?
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ····@rpw3.org (Rob Warnock) writes:
>
> > +---------------
> > | (setf (symbol-value 'x) 6)
> > +---------------
> >
> > There is no defined behavior in the absence of a global definition
> > of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
> > the SETF with a DEFVAR, then CLISP gives the same result as the others.
>
> I've seen statements like this before, but I can't think of anything
> in the spec that supports such a statement. Certainly, I don't see
> anything on the SYMBOL-VALUE page. Am I forgetting something obvious
> somewhere else?
I guess the point (of specifying undefined behavior in that case) is
that a compiler could optimize out the literal symbol reference and
just generate:
(movei.l 6 #x2001ab34)
but this can be done only if the global variable exists at run-time.
Of course, the symbol x and the place (symbol-value 'x) exist at
read-time and at compilation time, but without a DEFPARAMETER or
DEFVAR, the compiler could avoid generating the memory for X.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <····@mouse-potato.com> wrote:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > ····@rpw3.org (Rob Warnock) writes:
> >
> > > +---------------
> > > | (setf (symbol-value 'x) 6)
> > > +---------------
> > >
> > > There is no defined behavior in the absence of a global definition
> > > of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
> > > the SETF with a DEFVAR, then CLISP gives the same result as the others.
> >
> > I've seen statements like this before, but I can't think of anything
> > in the spec that supports such a statement. Certainly, I don't see
> > anything on the SYMBOL-VALUE page. Am I forgetting something obvious
> > somewhere else?
>
>
> I guess the point (of specifying undefined behavior in that case) is
> that a compiler could optimize out the literal symbol reference and
> just generate:
>
> (movei.l 6 #x2001ab34)
>
> but this can be done only if the global variable exists at run-time.
> Of course, the symbol x and the place (symbol-value 'x) exist at
> read-time and at compilation time, but without a DEFPARAMETER or
> DEFVAR, the compiler could avoid generating the memory for X.
That's the case for (setq x 6). This is a variable assignment.
But SETF of SYMBOL-VALUE is not a variable assignment, it's an update of
the value cell of a symbol object. All symbols have value cells,
regardless of whether they're declared as special variables.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Pascal Bourguignon wrote:
>>>+---------------
>>>| (setf (symbol-value 'x) 6)
>>>+---------------
>>>
>>>There is no defined behavior in the absence of a global definition
>>>of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
>>>the SETF with a DEFVAR, then CLISP gives the same result as the others.
>>
>>I've seen statements like this before, but I can't think of anything
>>in the spec that supports such a statement. Certainly, I don't see
>>anything on the SYMBOL-VALUE page. Am I forgetting something obvious
>>somewhere else?
>
> I guess the point (of specifying undefined behavior in that case) is
> that a compiler could optimize out the literal symbol reference and
> just generate:
>
> (movei.l 6 #x2001ab34)
>
> but this can be done only if the global variable exists at run-time.
> Of course, the symbol x and the place (symbol-value 'x) exist at
> read-time and at compilation time, but without a DEFPARAMETER or
> DEFVAR, the compiler could avoid generating the memory for X.
The convenience of the compiler is not the issue. The compiler could be
simpler or more efficient by the elimination of any number of language
features. The question is about the defined semantics of the language,
specifically, whether setf of symbol-value is defined in the absence
of a special proclamation on that symbol. I believe the semantics are
defined, although the ANS is not perfectly clear on the matter.
There is general agreement that execution of X or (SETF X ...) in
the absence of a special proclamation or declaration of X has no
defined semantics. Nonetheless, most implementations treat such a
free reference as a reference to the special variable, since Lisp has
worked that way since the second Eisenhauer administration, it is
very convenient when interacting with a lisp listener, and it is
usually sufficient to catch spelling and extent errors that the
compiler warns about free references. But this behavior is indeed not
defined by the ANS.
But symbol-value is different. Even the name implies (or at least
echoes the history) that symbol-value references the value slot of the
structure that implements a symbol. Many implementations no longer
implement the value attribute of a symbol that way, but for reasons
unrelated to storage efficiency. Still, there are scattered references
in the ANS that suggest that all symbols have a symbol-value property
that can be referenced by symbol-value and setf of symbol-value. See
first in the Glossary the entries for "value cell" and "cell". Then
see the dictionary page for cl:set, which never mentions variables at
all (except to note that cl:set cannot change a lexical variable).
cl:set is defined in terms of symbols, not dynamic variables...
Finally, se the dictionary entries for boundp and makunboundp, which
mention no restriction that the symbol must be proclaimed a special
variable. These are reuired to signal error if passed a non-symbol,
but there is no mention for a non-proclaimed symbol. Any symbol seems
to be legal, and it would be odd for boundp to work this way but for
symbol-value to be more restrictive.
Pascal Bourguignon <····@mouse-potato.com> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > ····@rpw3.org (Rob Warnock) writes:
> >
> > > +---------------
> > > | (setf (symbol-value 'x) 6)
> > > +---------------
> > >
> > > There is no defined behavior in the absence of a global definition
> > > of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
> > > the SETF with a DEFVAR, then CLISP gives the same result as the others.
> >
> > I've seen statements like this before, but I can't think of anything
> > in the spec that supports such a statement. Certainly, I don't see
> > anything on the SYMBOL-VALUE page. Am I forgetting something obvious
> > somewhere else?
>
> I guess the point (of specifying undefined behavior in that case) is
I guess I didn't make myself clear enough. Stephen Halfich and Barry
Margolin understood what I was saying, but apparently you got it
inside-out. So, I'll try again, this time less diplomatically:
Rob Warnock's post above is incorrect. SETF of SYMBOL-VALUE is not
the same thing as making a free reference to a variable, although most
(all?) implementations interpret the latter as being equivalent to the
former. SETF of SYMBOL-VALUE's behavior is defined over the domain of
*all* symbols. Anybody who wants to argue otherwise had better cite
chapter and verse, because the SYMBOL-VALUE entry in 10.2 (The Symbols
Dictionary) is perfectly clear on the matter. If you cannot support
your argument from the spec, stop spreading disinformation.
Thomas F. Burdick wrote:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
>
>>···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>>
>>
>>>····@rpw3.org (Rob Warnock) writes:
>>>
>>>
>>>>+---------------
>>>>| (setf (symbol-value 'x) 6)
>>>>+---------------
>>>>
>>>>There is no defined behavior in the absence of a global definition
>>>>of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
>>>>the SETF with a DEFVAR, then CLISP gives the same result as the others.
>>>
>>>I've seen statements like this before, but I can't think of anything
>>>in the spec that supports such a statement. Certainly, I don't see
>>>anything on the SYMBOL-VALUE page. Am I forgetting something obvious
>>>somewhere else?
>>
>>I guess the point (of specifying undefined behavior in that case) is
>
>
> I guess I didn't make myself clear enough. Stephen Halfich and Barry
> Margolin understood what I was saying, but apparently you got it
> inside-out. So, I'll try again, this time less diplomatically:
>
> Rob Warnock's post above is incorrect. SETF of SYMBOL-VALUE is not
> the same thing as making a free reference to a variable, although most
> (all?) implementations interpret the latter as being equivalent to the
> former. SETF of SYMBOL-VALUE's behavior is defined over the domain of
> *all* symbols. Anybody who wants to argue otherwise had better cite
> chapter and verse, because the SYMBOL-VALUE entry in 10.2 (The Symbols
> Dictionary) is perfectly clear on the matter. If you cannot support
> your argument from the spec, stop spreading disinformation.
"Perfectly clear" as in:
http://www.lispworks.com/reference/HyperSpec/Body/f_symb_5.htm
"symbol---a symbol that must have a value." under "Arguments and Values"
and
"Should signal unbound-variable if symbol is unbound and an attempt is
made to read its value. (No such error is signaled on an attempt to
write its value.)" under "Exceptional Situations"?
So must the symbol have a value or not in order to use SETF of
SYMBOL-VALUE? If it must have a value (as CLHS says it must) but
currently doesn't have one then how do we give it one without
DEFVAR/DEFPARAMETER as Rob suggests?
A literal reading of SYMBOL-VALUE's entry says:
No error is signaled on an attempt to write the value of a symbol (which
has to have a value) if it is unbound (and doesn't have a value).
David Sletten
In article <····················@twister.socal.rr.com>,
David Sletten <·····@slytobias.com> wrote:
> "Perfectly clear" as in:
> http://www.lispworks.com/reference/HyperSpec/Body/f_symb_5.htm
>
> "symbol---a symbol that must have a value." under "Arguments and Values"
>
> and
>
> "Should signal unbound-variable if symbol is unbound and an attempt is
> made to read its value. (No such error is signaled on an attempt to
> write its value.)" under "Exceptional Situations"?
>
> So must the symbol have a value or not in order to use SETF of
> SYMBOL-VALUE? If it must have a value (as CLHS says it must) but
> currently doesn't have one then how do we give it one without
> DEFVAR/DEFPARAMETER as Rob suggests?
>
> A literal reading of SYMBOL-VALUE's entry says:
> No error is signaled on an attempt to write the value of a symbol (which
> has to have a value) if it is unbound (and doesn't have a value).
The argument description is describing the argument to the SYMBOL-VALUE
fuction, not when using SETF.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin wrote:
> In article <····················@twister.socal.rr.com>,
> David Sletten <·····@slytobias.com> wrote:
>
>
>>"Perfectly clear" as in:
>>http://www.lispworks.com/reference/HyperSpec/Body/f_symb_5.htm
>>
>>"symbol---a symbol that must have a value." under "Arguments and Values"
>>
>>and
>>
>>"Should signal unbound-variable if symbol is unbound and an attempt is
>>made to read its value. (No such error is signaled on an attempt to
>>write its value.)" under "Exceptional Situations"?
>>
>>So must the symbol have a value or not in order to use SETF of
>>SYMBOL-VALUE? If it must have a value (as CLHS says it must) but
>>currently doesn't have one then how do we give it one without
>>DEFVAR/DEFPARAMETER as Rob suggests?
>>
>>A literal reading of SYMBOL-VALUE's entry says:
>>No error is signaled on an attempt to write the value of a symbol (which
>>has to have a value) if it is unbound (and doesn't have a value).
>
>
> The argument description is describing the argument to the SYMBOL-VALUE
> fuction, not when using SETF.
>
That's certainly a more consistent interpretation. But why then is
"new-value", which only applies to the use of SETF, described in the
same section as "value"? That part clearly applies to both SYMBOl-VALUE
and (SETF (SYMBOL-VALUE))--why not the part about "symbol"?
David Sletten
David Sletten <·····@slytobias.com> writes:
> Thomas F. Burdick wrote:
>
> > Pascal Bourguignon <····@mouse-potato.com> writes:
> >
> >
> >>···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> >>
> >>
> >>>····@rpw3.org (Rob Warnock) writes:
> >>>
> >>>
> >>>>+---------------
> >>>>| (setf (symbol-value 'x) 6)
> >>>>+---------------
> >>>>
> >>>>There is no defined behavior in the absence of a global definition
> >>>>of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
> >>>>the SETF with a DEFVAR, then CLISP gives the same result as the others.
> >>>
> >>>I've seen statements like this before, but I can't think of anything
> >>>in the spec that supports such a statement. Certainly, I don't see
> >>>anything on the SYMBOL-VALUE page. Am I forgetting something obvious
> >>>somewhere else?
> >>
> >>I guess the point (of specifying undefined behavior in that case) is
> >
> >
> > I guess I didn't make myself clear enough. Stephen Halfich and Barry
> > Margolin understood what I was saying, but apparently you got it
> > inside-out. So, I'll try again, this time less diplomatically:
> >
> > Rob Warnock's post above is incorrect. SETF of SYMBOL-VALUE is not
> > the same thing as making a free reference to a variable, although most
> > (all?) implementations interpret the latter as being equivalent to the
> > former. SETF of SYMBOL-VALUE's behavior is defined over the domain of
> > *all* symbols. Anybody who wants to argue otherwise had better cite
> > chapter and verse, because the SYMBOL-VALUE entry in 10.2 (The Symbols
> > Dictionary) is perfectly clear on the matter. If you cannot support
> > your argument from the spec, stop spreading disinformation.
>
> "Perfectly clear" as in:
> http://www.lispworks.com/reference/HyperSpec/Body/f_symb_5.htm
Yes, perfectly clear. Your argument below if fatuous. If one takes
your interpretation, the SYMBOL-VALUE entry is nonsensical; if one
assumes that the authors intended the entry to make sense, then it is
obvious that the restriction of having a value only applies to symbols
having their SYMBOL-VALUE read, as is elaborated at the bottom of the
entry.
> A literal reading of SYMBOL-VALUE's entry says:
> No error is signaled on an attempt to write the value of a symbol (which
> has to have a value) if it is unbound (and doesn't have a value).
>
The spec is written in ordinary English, it cannot be read as though
it were written with mathemtatical precision, and doing so is
completely fatuous. There are bugs in the spec, this isn't one of them.
Thomas F. Burdick wrote:
>
>
> Yes, perfectly clear. Your argument below if fatuous. If one takes
> your interpretation, the SYMBOL-VALUE entry is nonsensical; if one
> assumes that the authors intended the entry to make sense, then it is
> obvious that the restriction of having a value only applies to symbols
> having their SYMBOL-VALUE read, as is elaborated at the bottom of the
> entry.
>
>
I'm glad you're following along--I wouldn't say the entry is
nonsensical, but I was highlighting an evident contradiction. Your
assertion about the intentions of the authors is unfortunately
irrelevant. It is quite possible for one to make a serious effort at
communication yet still introduce ambiguity. Even you appear to grasp
this in your comment below. As I pointed out in my response to Barry
yesterday, no it is not _obvious_ that the restriction applies only to
reading. If it were as obvious as you've convinced yourself, then why
would it warrant even a parenthetical comment distinguishing reading
from writing?
>>A literal reading of SYMBOL-VALUE's entry says:
>>No error is signaled on an attempt to write the value of a symbol (which
>>has to have a value) if it is unbound (and doesn't have a value).
>>
>
> The spec is written in ordinary English, it cannot be read as though
> it were written with mathemtatical precision, and doing so is
> completely fatuous. There are bugs in the spec, this isn't one of them.
This is fantastic news. Now I no longer need expect consistency or
precision in the spec. Now I know that if I ever encounter anything
puzzling, all I need to do is turn to High Priest Thomas for his
orthodox pronouncements.
David Sletten
Thomas F. Burdick <···@conquest.OCF.Berkeley.EDU> wrote:
+---------------
| Pascal Bourguignon <····@mouse-potato.com> writes:
| > ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
| > > ····@rpw3.org (Rob Warnock) writes:
| > > > +---------------
| > > > | (setf (symbol-value 'x) 6)
| > > > +---------------
| > > >
| > > > There is no defined behavior in the absence of a global definition
| > > > of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
| > > > the SETF with a DEFVAR, then CLISP gives the same result as the others.
| > >
| > > I've seen statements like this before, but I can't think of anything
| > > in the spec that supports such a statement. Certainly, I don't see
| > > anything on the SYMBOL-VALUE page. Am I forgetting something obvious
| > > somewhere else?
| >
| > I guess the point (of specifying undefined behavior in that case) is
|
| I guess I didn't make myself clear enough. Stephen Halfich and Barry
| Margolin understood what I was saying, but apparently you got it
| inside-out. So, I'll try again, this time less diplomatically:
|
| Rob Warnock's post above is incorrect. SETF of SYMBOL-VALUE is not
| the same thing as making a free reference to a variable, although most
| (all?) implementations interpret the latter as being equivalent to the
| former. SETF of SYMBOL-VALUE's behavior is defined over the domain of
| *all* symbols.
+---------------
You're absolutely correct! My apologies, I misspoke! I used a completely
bogus example to make my real point [thus confounding the whole issue].
Burdick and others have made similar points as well. Let me try again...
From the CLHS Glossary, we have:
value n. ... 3. (of a symbol) the value of the dynamic variable
named by that symbol.
value cell n. Trad. (of a symbol) The place which holds the
value, if any, of the dynamic variable named by that symbol,
and which is accessed by symbol-value. See cell.
So clearly, if X is a dynamic variable in some dynamic binding
contour, then (setf (symbol-value 'x) 6) will set the value that
is returned by a naked reference to X in that same dynamic scope.
But since there is no such thing in the CLHS as a "global lexical
variable", it is undefined whether in the absence of a declaration
of X in the current scope a free reference to X should be treated
as dynamic, lexical, or throw an "unbound" exception. In *any* event
(symbol-value 'x) must return the most recent value set in the
current synamic scope.
Is that better, or have I just made things more muddled?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
(message (Hello 'Rob)
(you :wrote :on '(Mon, 10 Jan 2005 23:02:41 -0600))
(
RW> +---------------
RW> | (setf (symbol-value 'x) 6)
RW> +---------------
RW> There is no defined behavior in the absence of a global definition
RW> of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
RW> the SETF with a DEFVAR, then CLISP gives the same result as the others.
it's not interesting if it will be globally special - that whole chapter of
CLHS is about situations where variable is somewhere special, and somewhere
lexical.
what's about such example - isn't it more legal?
(let (x)
(locally (declare (special x)) (setf (symbol-value 'x) 6))
(defun foo (x) ;a lexical binding of x
(print x)
(let ((x (1+ x))) ;a special binding of x
(declare (special x)) ;and a lexical reference
(bar))
(1+ x))
(defun bar ()
(print (locally (declare (special x))
x)))
(foo 10))
or even
(let (x)
(declare (special x))
(setf (symbol-value 'x) 6)
(defun foo (x)
(print x)
(let ((x (1+ x)))
(declare (special x))
(bar))
(1+ x))
(defun bar ()
(print (locally (declare (special x))
x)))
(foo 10))
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "People, who lust for the Feel of keys on their fingertips (c)
Inity"))
(message (Hello 'Rob)
(you :wrote :on '(Mon, 10 Jan 2005 23:02:41 -0600))
(
RW> There is no defined behavior in the absence of a global definition
RW> of "x", e.g., "(defparameter x 6)" perhaps. And if you *do* replace
RW> the SETF with a DEFVAR, then CLISP gives the same result as the others.
CLISP gives the same result as the others only if there's declaim or
proclaim.
all (declare (special x)) are illegal?
if it's not illegal, in the expression
(let ((x (1+ x))
(declare (special x))
x)
should x in (1+ x) be special or not?
in CLISP it is, in other implementations - it's not.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "People, who lust for the Feel of keys on their fingertips (c)
Inity"))
Alex Mizrahi wrote:
> (let ((x (1+ x))
> (declare (special x))
> x)
>
> should x in (1+ x) be special or not?
> in CLISP it is, in other implementations - it's not.
It should not (see CLtS, secion 3.3.4, paragraph 7).
Paul
Paul F. Dietz wrote:
> Alex Mizrahi wrote:
>
> > (let ((x (1+ x))
> > (declare (special x))
> > x)
> >
> > should x in (1+ x) be special or not?
> > in CLISP it is, in other implementations - it's not.
>
> It should not (see CLtS, secion 3.3.4, paragraph 7).
this bug has been now fixed in the CLISP CVS.
(message (Hello 'Alex)
(you :wrote :to '(Rob Warnock) :on '(Tue, 11 Jan 2005 10:58:35 +0200))
(
AM> if it's not illegal, in the expression
AM> (let ((x (1+ x))
AM> (declare (special x))
AM> x)
AM> should x in (1+ x) be special or not?
AM> in CLISP it is, in other implementations - it's not.
a simple test without any global values or declarations:
(let ((x 5)) (let ((x (1+ x))) (declare (special x)) (print x)))
it prints 6 in lispworks, but says x is unbound in CLISP.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "People, who lust for the Feel of keys on their fingertips (c)
Inity"))