From: David Bakhash
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <cxjvhbks6ju.fsf@acs5.bu.edu>
This is a chunk of a post to comp.lang.perl.misc:
Tom Christiansen <···················@perl.com> writes:
> (This excerpt from perlfaq7 - Perl Language Issues
> ($Revision: 1.28 $, $Date: 1999/05/23 20:36:18 $)
> part of the standard set of documentation included with every
> valid Perl distribution, like the one on your system.
> See also http://language.perl.com/newdocs/pod/perlfaq7.html
> if your negligent system adminstrator has been remiss in his duties.)
>
> How can I access a dynamic variable while a similarly named lexical is in
> scope?
> You can do this via symbolic references, provided you haven't set
> `use strict "refs"'. So instead of $var, use `${'var'}'.
>
> local $var = "global";
> my $var = "lexical";
>
> print "lexical is $var\n";
>
> no strict 'refs';
> print "global is ${'var'}\n";
>
> If you know your package, you can just mention it explicitly, as in
> $Some_Pack::var. Note that the notation $::var is *not* the dynamic
> $var in the current package, but rather the one in the `main'
> package, as though you had written $main::var. Specifying the
> package directly makes you hard-code its name, but it executes
> faster and avoids running afoul of `use strict "refs"'.
okay. So, how do you do the same thing in Lisp?
of course, I'm aware of #'symbol-value, but hardly ever actually needed to use
it. So I gave it a shot, and was surprised by what I saw:
CL-USER 1 > (setq x 3)
3
CL-USER 2 > (let ((x 4))
(list x (symbol-value 'x)))
(4 3)
;; okay. So that's good. That's what I wanted to see. But then I tried
;; this:
CL-USER 3 > (defvar y 3)
Y
CL-USER 4 > (let ((y 4))
(list y (symbol-value 'y)))
(4 4)
;; I thought defvar made a special variable, and that's what symbol-value is
;; supposed to deal with, right? :
;; SYMBOL-VALUE can see dynamic variables.
;; (From the HS)
I guess I must be confusing defvar with setq when run at the top-level. Even
so, isn't a defvar a special, dynamic variable? i.e. shouldn't it be affected
by #'(setf symbol-value)?
dave
From: Axel Schairer
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <fm9u2r4b8so.fsf@clair.dai.ed.ac.uk>
David Bakhash <·····@bu.edu> writes:
> CL-USER 3 > (defvar y 3)
> Y
> CL-USER 4 > (let ((y 4))
> (list y (symbol-value 'y)))
> (4 4)
> ;; I thought defvar made a special variable, and that's what symbol-value is
> ;; supposed to deal with, right? :
What's the reason for you to think it didn't? What do I miss? You
dynamically bind USER::Y to 4, and that's what symbol-value sees
(global is just another name for dynamic in the toplevel environment
in which there are no explicit bindings, isn't it). To my
understanding this is what you should expect. The DEFVAR form made
the symbol CL-USER::Y to be the name of a special (= dynamic) variable
(from the hyperspec, mac_defparametercm_defvar.html)
| defparameter and defvar establish name as a dynamic variable.
Consequently the binding of CL-USER::Y in the LET form is a dynamic
binding, so that SYMBOL-VALUE should see it (see the comment you quote
from the hyperspec below).
(By the way: (PROGN (SETQ X 1) (DEFVAR X 2) X) => 1 not => 2? I don't
think that is the problem here, though.)
> ;; SYMBOL-VALUE can see dynamic variables.
> ;; (From the HS)
The whole example from which you quote (taken from the hyper spec
.../Body/acc_symbol-value.html) is:
| (setf (symbol-value 'a) 1) => 1
[snip]
| ;; SYMBOL-VALUE can see dynamic variables.
| (let ((a 2))
| (declare (special a))
| (symbol-value 'a)) => 2
Doesn't that exactly reproduce what you found, considering that DEFVAR
effectively makes the symbol name a special variable (so you get the
effect of (DECLARE (SPECIAL Y)) without writing it)?
> I guess I must be confusing defvar with setq when run at the top-level. Even
> so, isn't a defvar a special, dynamic variable? i.e. shouldn't it be affected
> by #'(setf symbol-value)?
Pardon me? Yes, #'(SETF SYMBOL-VALUE) updates the current dynamic
binding of its argument:
USER(1): (defvar z 1) ; Z => 1
USER(2): (let ((z 2)) ; Here is a new dynamic binding
; for z (Z => 2)
(setf (symbol-value 'z) 3)
z) ; => 3
USER(3): z ; => 1 (the old (global) value
; of the special variable)
But how does this contradict the results you got?
Cheers, Axel
From: Arthur Lemmens
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <378FA1FC.77078F8B@simplex.nl>
David Bakhash wrote:
>
> This is a chunk of a post to comp.lang.perl.misc:
I didn't bother to read the perl stuff, but I don't think that's really
necessary for answering your question.
> of course, I'm aware of #'symbol-value, but hardly ever actually needed to use
> it. So I gave it a shot, and was surprised by what I saw:
>
> CL-USER 1 > (setq x 3)
> 3
>
> CL-USER 2 > (let ((x 4))
> (list x (symbol-value 'x)))
> (4 3)
>
> ;; okay. So that's good. That's what I wanted to see.
Yes. When evaluating (SETQ X 3), there's no lexical binding for X,
so SETQ assumes you're referring to a dynamic variable, to which
it assigns the value 3.
When evaluating (LET ((X 4)) ...), there's no SPECIAL declaration for X,
so LET binds X lexically to 4 and the X in (LIST X ...) accesses the value
of that lexical binding. Of course, SYMBOL-VALUE is defined to acess the
value of the dynamic variable named by its argument, so it returns 3.
> ;; But then I tried this:
>
> CL-USER 3 > (defvar y 3)
> Y
>
> CL-USER 4 > (let ((y 4))
> (list y (symbol-value 'y)))
> (4 4)
>
> I thought defvar made a special variable, and that's what symbol-value is
> supposed to deal with, right? :
Yes, right. But because Y has been declared to be special (by DEFVAR),
LET is not establishing a lexical binding for Y here, but a dynamic binding!
In other words, LET is changing the value of the dynamic (= special)
variable Y to 4, and both the Y in (LIST Y ...) and the Y in
(SYMBOL-VALUE 'Y) access that value.
> I guess I must be confusing defvar with setq when run at the top-level.
> Even so, isn't a defvar a special, dynamic variable? i.e. shouldn't it
> be affected by #'(setf symbol-value)?
Yes. I think you've missed something about LET, not about DEFVAR or
SYMBOL-VALUE.
Arthur Lemmens
From: David Bakhash
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <cxju2r4s008.fsf@acs5.bu.edu>
I was missing something about special variables for a long time. It's a
simple thing. Thank god I never got hanged with it, though now I can see how
one easily can hurt himself with special variables.
Basically, making a variable special means that its _name_, when encountered
again, implicitly causes it to be dynamic. I always followed the rule that
global (hence special) vars should be denoted (i.e. by *<var>*), but not until
now do I see why it's extra important.
Of course, that's how things like:
(defun print-bar (x)
(let ((*standard-output* foo))
(print x)))
can work the way they do. Not using dynamic variables too much, it's not
surprising how this slipped by me. Thanks for the help.
dave
From: Barry Margolin
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <eHJk3.1430$KM3.422618@burlma1-snr2>
In article <·················@simplex.nl>,
Arthur Lemmens <·······@simplex.nl> wrote:
>
>David Bakhash wrote:
>> of course, I'm aware of #'symbol-value, but hardly ever actually needed to use
>> it. So I gave it a shot, and was surprised by what I saw:
>>
>> CL-USER 1 > (setq x 3)
>> 3
>>
>> CL-USER 2 > (let ((x 4))
>> (list x (symbol-value 'x)))
>> (4 3)
>>
>> ;; okay. So that's good. That's what I wanted to see.
>
>Yes. When evaluating (SETQ X 3), there's no lexical binding for X,
>so SETQ assumes you're referring to a dynamic variable, to which
>it assigns the value 3.
Note that this is implementation-dependent, because the CL specification
doesn't actually say precisely what should be done in this situation. Most
implementations just set the dynamic value of X, but I think CMUCL will
assume a SPECIAL proclamation, which is pervasive.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Vassil Nikolov
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <l03130302b3b9f992892e@195.138.129.92>
Barry Margolin wrote: [1999-07-19 17:58 +0000]
> In article <·················@simplex.nl>,
> Arthur Lemmens <·······@simplex.nl> wrote:
[...]
> >When evaluating (SETQ X 3), there's no lexical binding for X,
> >so SETQ assumes you're referring to a dynamic variable, to which
> >it assigns the value 3.
>
> Note that this is implementation-dependent, because the CL specification
> doesn't actually say precisely what should be done in this situation. Most
> implementations just set the dynamic value of X, but I think CMUCL will
> assume a SPECIAL proclamation, which is pervasive.
This caused me to re-RTFM. I still think it is unreasonable for SETQ to
do a special proclamation as a side effect, but I expected that I would
find something calling this illegal in a definitive way. That I didn't find.
Besides, I also notice that what CLtL says and what CLHS says is not the
same, and I cannot say if the two fully agree or not. (Yes, I know that
CLHS takes precedence over CLtL, but I expected that this issue did not
change between the two.)
CLtL, 5.1.2. Variables [p. 70 of CLtL2]
Which of the two kinds of variable is referred to when a symbol is
evaluated depends on the context of the evaluation. The general
rule is that if the symbol occurs textually within a program construct
that creates a _binding_ for a variable of the same name, then the
reference is to the variable specified by the binding; if no such
program construct textually contains the reference, then it is taken
to refer to the special variable of that name.
(This talks about evaluation; CLtL says in 7.1.2. Assignment [p. 121 of
CLtL2] that variables in SETQ forms `are interpreted [...] according to
the usual rules' and I take that to refer to the above.)
I take the above excerpt from 5.1.2 to mean that every case of evaluating
a variable is well-defined. On the other hand:
CLHS, 3.1.2.1.1.2 Dynamic Variables
A _variable_ is a _dynamic variable_ if one of the following conditions hold:
* It is locally declared or globally proclaimed special.
* It occurs textually within a _form_ that creates a _dynamic binding_
for a _variable_ of the _same name_, and the _binding_ is not
_shadowed_ [2] by a _form_ that creates a _lexical binding_ of the
same _variable name_.
This apparently leaves undefined the case of an undeclared/unproclaimed
variable occurring in a top-level form which does not create a binding for
that variable.
I feel like I am missing something.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
From: Kent M Pitman
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <sfwlnca4wtu.fsf@world.std.com>
Vassil Nikolov <········@poboxes.com> writes:
>
> Barry Margolin wrote: [1999-07-19 17:58 +0000]
>
> > In article <·················@simplex.nl>,
> > Arthur Lemmens <·······@simplex.nl> wrote:
> [...]
> > >When evaluating (SETQ X 3), there's no lexical binding for X,
> > >so SETQ assumes you're referring to a dynamic variable, to which
> > >it assigns the value 3.
> >
> > Note that this is implementation-dependent, because the CL specification
> > doesn't actually say precisely what should be done in this situation. Most
> > implementations just set the dynamic value of X, but I think CMUCL will
> > assume a SPECIAL proclamation, which is pervasive.
>
> This caused me to re-RTFM. I still think it is unreasonable for SETQ to
> do a special proclamation as a side effect, but I expected that I would
> find something calling this illegal in a definitive way. That I didn't find.
Well, the matter of the meaning is left vague exactly so some vendors can
declare the variable special as a "helpful" thing. Doing a side-effect on
a persisting basis is less friendly, but I don't know if that's something
illegal. It's already non-conforming to have done that act, so the effect
beyond that is a little hard to legislate. That doesn't mean one can't
try to claim the spec has jurisdiction, but they will be stretching.
You could MAYBE stretch 1.6 (Language Extensions), where it says that
implementations can have extensions as long as they don't affect the
correctness of conforming programs to give you some ammo when talking
to a vendor. But if you tell them I put you up to it, I'll deny it.
On the other hand, if you leave the issue of "conformance" out of it,
you're welcome to quote me as having said I think that the idea of
making a persistent side-effect on the basis of a typo seems to me
like a "bad idea".
> Besides, I also notice that what CLtL says and what CLHS says is not the
> same, and I cannot say if the two fully agree or not. (Yes, I know that
> CLHS takes precedence over CLtL, but I expected that this issue did not
> change between the two.)
>
> CLtL, 5.1.2. Variables [p. 70 of CLtL2]
>
> Which of the two kinds of variable is referred to when a symbol is
> evaluated depends on the context of the evaluation. The general
> rule is that if the symbol occurs textually within a program construct
> that creates a _binding_ for a variable of the same name, then the
> reference is to the variable specified by the binding; if no such
> program construct textually contains the reference, then it is taken
> to refer to the special variable of that name.
>
> (This talks about evaluation; CLtL says in 7.1.2. Assignment [p. 121 of
> CLtL2] that variables in SETQ forms `are interpreted [...] according to
> the usual rules' and I take that to refer to the above.)
>
> I take the above excerpt from 5.1.2 to mean that every case of evaluating
> a variable is well-defined. On the other hand:
>
> CLHS, 3.1.2.1.1.2 Dynamic Variables
>
> A _variable_ is a _dynamic variable_ if one of the following conditions hold:
>
> * It is locally declared or globally proclaimed special.
>
> * It occurs textually within a _form_ that creates a _dynamic binding_
> for a _variable_ of the _same name_, and the _binding_ is not
> _shadowed_ [2] by a _form_ that creates a _lexical binding_ of the
> same _variable name_.
>
> This apparently
and almost surely intentionally.
> leaves undefined the case of an undeclared/unproclaimed
> variable occurring in a top-level form which does not create a binding for
> that variable.
>
> I feel like I am missing something.
Probably not. Just reaching for something that is not there. My
vague recollection is that this was a delicate area and we tried hard
not to take an official position on it so as not to create a big
committee fight. I should probably have been more explicit about that
in the document, though.
A number of us had our hand on this text, btw. Not just me but
Sandra Loosemore, David Moon, Richard Gabriel, etc. I'm not positive
who made the decision on this particular wording. Not that it matters,
btw. But it helps you understand why I may not know what was intended
to a high degree of accuracy.
Not that what was intended matters. Technically, only the words do.
Though obviously there are places where that's a pain.
From: Vassil Nikolov
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <l03130301b3bc6869a3d6@195.138.129.77>
Kent M Pitman wrote [1999-07-21 01:26 +0000]
an explanation about referring to variables in the absence of
binding forms and special proclamations.
[...]
> On the other hand, if you leave the issue of "conformance" out of it,
> you're welcome to quote me as having said I think that the idea of
> making a persistent side-effect on the basis of a typo seems to me
> like a "bad idea".
Now that I see that I have not missed some important piece of the
language specification, and that indeed the case about such variables
is left unspecified, I wouldn't (and couldn't) talk about conformance,
but at best about an implementation providing such behaviour that
is consistent with the rest of the language and logical to the user.
[...]
Thanks for the explanation. This is to me exactly the kind of stuff
that makes the Issues so useful (though I don't see how in this
particular case such commentary could be included amont the
Issues).
Thanks also to a private communication I received about CMUCL
I see now that I was wrong to call CMUCL's behaviour a bug,
and that in fact it is quite logical and also under user control.
> (defvar *top-level-auto-declare* :warn
> "This variable controls whether assignments to unknown variables at top-level
> (or in any other call to EVAL of SETQ) will implicitly declare the variable
> SPECIAL. These values are meaningful:
> :WARN -- Print a warning, but declare the variable special (the default.)
> T -- Quietly declare the variable special.
> NIL -- Never declare the variable, giving warnings on each use.")
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
From: Vassil Nikolov
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <l03130300b3b685d518c8@195.138.129.82>
On 1999-07-17 10:23 +0000,
Rob Warnock wrote:
[...]
> There's no defined way in the
> Common Lisp standard to have a global lexical variable.
(Although the user can sort of emulate that by DEFINE-SYMBOL-MACRO.)
But there is a way to have a global dynamic variable.
> Yes, CLISP
> and maybe some other Lisps give the above behavior, but CMUCL, for
> example, gives this:
>
> * (setq x 3)
> Warning: Declaring X special.
> 3
> * (let ((x 4))
> (list x (symbol-value 'x)))
> (4 4)
> * x
> 3
> *
>
This seems to be a bug. (I don't have CMUCL handy to try to replicate that.)
If the variable is not a global dynamic variable, a SETQ at top level (i.e. not
within the scope of a LET) should _assume_ the variable to be such but
*not* _proclaim_ it special. The behaviour in the example above can be
explained by the SETQ doing just the latter (illegally); the correct value
of the LET form above is (4 3). Now if there had been a (DEFVAR X) or
a (PROCLAIM '(SPECIAL X)) before the SETQ above, then there would not
be a warning and the values returned above would be correct. The other
way to make the above results correct would be to insert into the LET
form a (DECLARE (SPECIAL X)).
> (At least CMUCL prints a warning.)
Which is good; but given the above bug the warning is a misnomer;
the actual behaviour apparently would be matched by `Warning:
Proclaiming X special.'
>
> However, CMUCL has its quirks in this area, too, I think. Suppose you
> never set the "variable", only the "symbol"? Then it looks like you
> can get a sort of "global lexical":
>
> * (setf (symbol-value 'y) 3) ; instead of (setf y 3)
> 3
> * (let ((y 4))
> (list y (symbol-value 'y)))
> (4 3)
> * y
> 3
I see no global lexical here. The value of a symbol when outside of
the scope of a binding form (e.g. at top level) is the current dynamic
value of that symbol. The accessor for that is SYMBOL-VALUE.
> *
>
> So what's wrong with this? Maybe nothing, but... The HyperSpec says that
> the argument to "symbol-value" (even in the "stef" form) must already have
> a value.
What does the CLHS say exactly to that effect?
> But at the same time, it says:
>
> 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.)
>
> Now, for the "unbound" case, does "no error is signaled on...write" mean
> that the write is guaranteed to succeed, or that it *may* fail but that
> no error is signalled? Without some clarification, I don't see that the
> behavior can be counted on.
By definition, SETF of SYMBOL-VALUE of FOO is identical to SET of FOO,
and that doesn't fail if FOO is unbound.
Finally, perhaps this would serve as an additional clarification:
;;; FOO is _not_ a global dynamic variable in this example
(let ((foo 1))
(setf (symbol-value 'foo) 2)
(values foo (symbol-value 'foo)))
=> 1, 2 ;within the scope of the LET, FOO accesses the local lexical value
(let ((foo 1))
(declare (special foo))
(setf (symbol-value 'foo) 2)
(values foo (symbol-value 'foo)))
=> 2, 2 ;no lexical variables in this form
Posted by Deja's mail-to-news gateway.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
From: Rob Warnock
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <7msabe$1uda5@fido.engr.sgi.com>
Vassil Nikolov <········@poboxes.com> wrote [some useful stuff, then]:
+---------------
| Rob Warnock wrote:
| > So what's wrong with this? Maybe nothing, but... The HyperSpec says that
| > the argument to "symbol-value" (even in the "stef" form) must already have
| > a value.
|
| What does the CLHS say exactly to that effect?
+---------------
At the beginning of <URL:http://www.harlequin.com/education/books/
HyperSpec/Body/acc_symbol-value.html> it says:
Accessor SYMBOL-VALUE
Syntax:
symbol-value symbol => value
(setf (symbol-value symbol) new-value)
Arguments and Values:
[*]==> symbol---a symbol that must have a value.
value, new-value---an object.
Description:
Accesses the symbol's value cell.
On the surface, it seemed to me (a still-naive CL & CLHS user) that the
"must have a value"[*] restriction should apply to the "setf" form too.
[...except for the stuff later about exceptions, which somewhat contradicted
the above.]
Note that this confusion/question somewhat resembles a thread of some
days ago concerning (setf (gethash <key> <ht> <init-value>) <new-value>)...
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
From: Vassil Nikolov
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <l03130302b3b792b36f5b@195.138.129.93>
Rob Warnock wrote: [1999-07-18 10:30 +0000]
[on SETF of SYMBOL-VALUE of an unbound symbol]
> At the beginning of <URL:http://www.harlequin.com/education/books/
> HyperSpec/Body/acc_symbol-value.html> it says:
>
> Accessor SYMBOL-VALUE
> Syntax:
> symbol-value symbol => value
> (setf (symbol-value symbol) new-value)
>
> Arguments and Values:
> [*]==> symbol---a symbol that must have a value.
> value, new-value---an object.
>
> Description:
> Accesses the symbol's value cell.
>
> On the surface, it seemed to me (a still-naive CL & CLHS user) that the
> "must have a value"[*] restriction should apply to the "setf" form too.
I suppose that this might be true if the quoted phrase is taken just
by itself. Some formal evidence that the phrase pertains only to
access for reading and not to access for writing:
(1) The meaning of `must' is defined in terms of error handling:
In places where the words ``must,'' ``must not,'' or ``may not''
are used, then ``the consequences are undefined'' if the stated
requirement is not met and no specific consequence is explicitly
stated. [CLHS 1.4.2]
So whatever the Exceptional Situations subsection says is the
definitive meaning of `must have a value' indeed:
> [...except for the stuff later about exceptions, which somewhat contradicted
> the above.]
(By the way, CLtL, section 1.2.4, defines `must' in a simpler way
directly related to errors: `In places where it is stated that so-and-so
``must'' or ``must not'' or ``may not'' be the case, then it ``is an error''
if the stated requirement is not met.')
(2) The description of SET (HyperSpec/Body/fun_set.html#set) says that
(set symbol value) == (setf (symbol-value symbol) value)
and SET has no requirements to the value of its first argument.
Of course, the above exercise is redundant since it is obviously
absurd to require that the symbol has a value before it is set to
a new value.
> Note that this confusion/question somewhat resembles a thread of some
> days ago concerning (setf (gethash <key> <ht> <init-value>) <new-value>)...
The SYMBOL-VALUE case is simpler---it does not have an optional
argument to use in case there is no value. And the treatment is
different: figuratively speaking, trying to obtain the value of a
valueless symbol produces the answer `Huh?' while trying to obtain
the value for an absent key in a hashtable produces the answer `None.'
The issue of already having a value does arise in the case of modify
macros (e.g. (PUSH 'FOO (SYMBOL-VALUE 'BAR))). In fact, it is this
kind of macros that really justifies the concept of places.
Posted via Deja's mail-to-news gateway.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
From: Kent M Pitman
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <sfwg12lg8g8.fsf@world.std.com>
Vassil Nikolov <········@poboxes.com> writes:
> Rob Warnock wrote: [1999-07-18 10:30 +0000]
>
> [on SETF of SYMBOL-VALUE of an unbound symbol]
> > At the beginning of <URL:http://www.harlequin.com/education/books/
> > HyperSpec/Body/acc_symbol-value.html> it says:
> >
> > Accessor SYMBOL-VALUE
> > Syntax:
> > symbol-value symbol => value
> > (setf (symbol-value symbol) new-value)
> >
> > Arguments and Values:
> > [*]==> symbol---a symbol that must have a value.
> > value, new-value---an object.
> >
> > Description:
> > Accesses the symbol's value cell.
> >
> > On the surface, it seemed to me (a still-naive CL & CLHS user) that the
> > "must have a value"[*] restriction should apply to the "setf" form too.
>
> I suppose that this might be true if the quoted phrase is taken just
> by itself.
This sure does look to me like an edit-o. I am not infallible, and it's
reasonable to assume there are such. Before you start trying to find
rationality in every strange thing you find, it's worth at least considering
the possibility of simple error.
I probably defined the args while editing up SYMBOL-VALUE and added
the SETF thing later, without looking to see if it bore additional,
uwanted constraint.
From: Vassil Nikolov
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <l03130304b3b7ea0e7f24@195.138.129.96>
Kent M Pitman wrote: [1999-07-18 17:43 +0000]
> Vassil Nikolov <········@poboxes.com> writes:
>
> > Rob Warnock wrote: [1999-07-18 10:30 +0000]
> >
> > [on SETF of SYMBOL-VALUE of an unbound symbol]
> > > At the beginning of <URL:http://www.harlequin.com/education/books/
> > > HyperSpec/Body/acc_symbol-value.html> it says:
[...]
> > > [*]==> symbol---a symbol that must have a value.
[...]
> > > On the surface, it seemed to me (a still-naive CL & CLHS user) that the
> > > "must have a value"[*] restriction should apply to the "setf" form too.
> >
> > I suppose that this might be true if the quoted phrase is taken just
> > by itself.
>
> This sure does look to me like an edit-o. I am not infallible, and it's
> reasonable to assume there are such. Before you start trying to find
> rationality in every strange thing you find, it's worth at least considering
> the possibility of simple error.
In fact I did consider that, but I thought that it would be too easy
and uninteresting to just say that the specification could do with
some correction, and took up the harder (though perhaps perverse)
task to see if it couldn't be justified the way it is. (There is a
proverb in Bulgarian that calls such things `looking for a calf under
the ox'...)
> I probably defined the args while editing up SYMBOL-VALUE and added
> the SETF thing later, without looking to see if it bore additional,
> uwanted constraint.
I hope your to-correct list for the standard hasn't overflowed yet.
Have a nice day or night,
Vassil (who, too, appreciates CLHS *greatly*).
Posted via Deja's mail-to-news gateway.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
From: Rob Warnock
Subject: Re: FAQ 7.17: How can I access a dynamic variable while a similarly named lexical is in scope?
Date:
Message-ID: <7mplj7$pfcu@fido.engr.sgi.com>
David Bakhash <·····@bu.edu> wrote:
+---------------
| So I gave it a shot, and was surprised by what I saw:
| CL-USER 1 > (setq x 3)
| 3
| CL-USER 2 > (let ((x 4))
| (list x (symbol-value 'x)))
| (4 3)
| ;; okay. So that's good. That's what I wanted to see.
+---------------
Well, don't start depending on that. There's no defined way in the
Common Lisp standard to have a global lexical variable. Yes, CLISP
and maybe some other Lisps give the above behavior, but CMUCL, for
example, gives this:
* (setq x 3)
Warning: Declaring X special.
3
* (let ((x 4))
(list x (symbol-value 'x)))
(4 4)
* x
3
*
(At least CMUCL prints a warning.)
However, CMUCL has its quirks in this area, too, I think. Suppose you
never set the "variable", only the "symbol"? Then it looks like you
can get a sort of "global lexical":
* (setf (symbol-value 'y) 3) ; instead of (setf y 3)
3
* (let ((y 4))
(list y (symbol-value 'y)))
(4 3)
* y
3
*
So what's wrong with this? Maybe nothing, but... The HyperSpec says that
the argument to "symbol-value" (even in the "stef" form) must already have
a value. But at the same time, it says:
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.)
Now, for the "unbound" case, does "no error is signaled on...write" mean
that the write is guaranteed to succeed, or that it *may* fail but that
no error is signalled? Without some clarification, I don't see that the
behavior can be counted on.
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA