From: Vladimir V. Zolotych
Subject: (declare (special foo))
Date: 
Message-ID: <3A5B5887.5E08616C@eurocom.od.ua>
This is a multi-part message in MIME format.
--------------3A94822545701C559476F5C1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

  Hello,

I've confused by special variables.

What the following LET should return ? (Peter Norvig
Paradigms of AI Programming pp 93)

# 1

(setf a 'global-a)
(defvar *b* 'global-b)
(defun fn () *b*)
(let ((a 'local-a)
      (*b* 'local-b))
  (list a *b* (fn) (symbol-value 'a) (symbol-value '*b*)))

I've tried and see
(LOCAL-A LOCAL-B LOCAL-B LOCAL-A LOCAL-B)

(CMU Common Lisp release x86-linux 2.4.22  3 October 2000 build 1154)

For what purpose SYMBOL-VALUE stands for ?

If I insert 
  (setf (symbol-value *b*) 'new-global-b)
in the LET above what should happen (I've done that
but couldn't notice anything).

Quote from the same book (pp. 94) "A special variable has
indefinite scope and dynamic extent". What happens with
extent of the *my-special* inside following LET:

# 2
(defvar *my-special* 0)

x(let ((*my-special* 2))
  ;; .........
  )
How I should think about entity named *my-special* inside the 
LET above (fig 2)?

Is it possible to make a variable not special neither lexical ?

If I can manage that the example #1 would work I suspect.

(Peter Norvig says the result should be 
  (LOCAL-A LOCAL-B LOCAL-B GLOBAL-A LOCAL-B) )

Thanks

-- 
Vladimir Zolotych                         ······@eurocom.od.ua
--------------3A94822545701C559476F5C1
Content-Type: text/x-vcard; charset=us-ascii;
 name="gsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vladimir V. Zolotych
Content-Disposition: attachment;
 filename="gsmith.vcf"

begin:vcard 
n:Zolotych;Valdimir V.
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
·····················@eurocom.od.ua
x-mozilla-cpt:;0
fn:Valdimir V. Zolotych
end:vcard

--------------3A94822545701C559476F5C1--

From: Christophe Rhodes
Subject: Re: (declare (special foo))
Date: 
Message-ID: <sqn1d0a9un.fsf@lambda.jesus.cam.ac.uk>
"Vladimir V. Zolotych" <······@eurocom.od.ua> writes:

> (setf a 'global-a)
> (defvar *b* 'global-b)
> (defun fn () *b*)
> (let ((a 'local-a)
>       (*b* 'local-b))
>   (list a *b* (fn) (symbol-value 'a) (symbol-value '*b*)))
> 
> I've tried and see
> (LOCAL-A LOCAL-B LOCAL-B LOCAL-A LOCAL-B)
> 
> (CMU Common Lisp release x86-linux 2.4.22  3 October 2000 build 1154)

I won't comment too much on this, but this is definitely a confusing
issue; I'm certainly not sure of the "right thing" here.

CMUCL, in contrast to most other implementations of Common Lisp,
treats setf of a previously unknown variable at top level as an
implicit special declaration as well; it should have told you of this,
by outputting

Warning:  Declaring A special.

during the execution of this. Given this, it's not surprising that you
can't see any difference between the behaviour of a and *b*. I don't
think that there is any way in CMUCL of getting a top-level lexical
variable (referencable with symbol-value) short of explicitly doing

* (setf (symbol-value 'a) 'global-a)

which you should replace your first line above to get the desired
result.

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 524 842
(FORMAT T "(·@{~w ········@{~w~^ ~})" 'FORMAT T "(·@{~w ········@{~w~^ ~})")
From: Raymond Toy
Subject: Re: (declare (special foo))
Date: 
Message-ID: <4nn1d030ei.fsf@rtp.ericsson.se>
>>>>> "Christophe" == Christophe Rhodes <·····@cam.ac.uk> writes:


    Christophe> during the execution of this. Given this, it's not surprising that you
    Christophe> can't see any difference between the behaviour of a and *b*. I don't
    Christophe> think that there is any way in CMUCL of getting a top-level lexical
    Christophe> variable (referencable with symbol-value) short of explicitly doing

I think there is some way to do this, but I can't remember what magic
variable needs to be set.  It's not documented anywhere other than the
source code.

If you set this, it causes some other strange things to happen, I
think.

Ray
From: Christophe Rhodes
Subject: Re: (declare (special foo))
Date: 
Message-ID: <sq7l41re8m.fsf@lambda.jesus.cam.ac.uk>
Raymond Toy <···@rtp.ericsson.se> writes:

> >>>>> "Christophe" == Christophe Rhodes <·····@cam.ac.uk> writes:
> 
> 
>     Christophe> during the execution of this. Given this, it's not surprising that you
>     Christophe> can't see any difference between the behaviour of a and *b*. I don't
>     Christophe> think that there is any way in CMUCL of getting a top-level lexical
>     Christophe> variable (referencable with symbol-value) short of explicitly doing
> 
> I think there is some way to do this, but I can't remember what magic
> variable needs to be set.  It's not documented anywhere other than the
> source code.

Found it!

* (describe '*top-level-auto-declare*)

*TOP-LEVEL-AUTO-DECLARE* is an external symbol in the EXTENSIONS package.
It is a special variable; its value is :WARN.
   WARN is an external symbol in the KEYWORD package.
   It is a constant; its value is :WARN.
Special documentation:
  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.
 
> If you set this, it causes some other strange things to happen, I
> think.

Well, every use of a variable gives you a compiler/evaluator warning
of an undefined variable. I got too lost somewhere in the definition
of with-compilation-unit in the cmucl source to grasp how to get rid
of this behaviour; some kind of deep-reaching modification is almost
certainly necessary. Certainly it's irritating, but I'm no expert on
the code and I can't see how to change it easily.

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 524 842
(FORMAT T "(·@{~w ········@{~w~^ ~})" 'FORMAT T "(·@{~w ········@{~w~^ ~})")
From: Rainer Joswig
Subject: toplevel variables in CMUCL, get rid of the SPECIAL declaration!
Date: 
Message-ID: <joswig-D92FE1.04185010012001@news.is-europe.net>
In article <··············@lambda.jesus.cam.ac.uk>, Christophe Rhodes 
<·····@cam.ac.uk> wrote:

> "Vladimir V. Zolotych" <······@eurocom.od.ua> writes:
> 
> > (setf a 'global-a)
> > (defvar *b* 'global-b)
> > (defun fn () *b*)
> > (let ((a 'local-a)
> >       (*b* 'local-b))
> >   (list a *b* (fn) (symbol-value 'a) (symbol-value '*b*)))
> > 
> > I've tried and see
> > (LOCAL-A LOCAL-B LOCAL-B LOCAL-A LOCAL-B)
> > 
> > (CMU Common Lisp release x86-linux 2.4.22  3 October 2000 build 1154)
> 
> I won't comment too much on this, but this is definitely a confusing
> issue; I'm certainly not sure of the "right thing" here.

just my personal opinion: I think CMUCL should better return
(LOCAL-A LOCAL-B LOCAL-B GLOBAL-A LOCAL-B) .

What is the opinion of CMUCL users?

-- 
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Christophe Rhodes
Subject: Re: toplevel variables in CMUCL, get rid of the SPECIAL declaration!
Date: 
Message-ID: <sqitnnabuj.fsf@lambda.jesus.cam.ac.uk>
Rainer Joswig <······@corporate-world.lisp.de> writes:

> In article <··············@lambda.jesus.cam.ac.uk>, Christophe Rhodes 
> <·····@cam.ac.uk> wrote:
> 
> > I won't comment too much on this, but this is definitely a confusing
> > issue; I'm certainly not sure of the "right thing" here.
> 
> just my personal opinion: I think CMUCL should better return
> (LOCAL-A LOCAL-B LOCAL-B GLOBAL-A LOCAL-B) .
> 
> What is the opinion of CMUCL users?

Can you give an example of when shadowing a global lexical variable is
useful? I really haven't yet come across a use for this, though I
grant you that I haven't been programming in lisp for as long as most
readers here.

Basically, I would guess that no-one actually does
(setf foo 'bar)
at top-level in a lisp file. Sure, we would at the top-level
interaction loop, while we're testing things, but I would guess not in
a real application (please correct me if I'm wrong).

I suppose I just can't see why we'd want a global lexical variable;
can anyone enlighten me on this?

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 524 842
(FORMAT T "(·@{~w ········@{~w~^ ~})" 'FORMAT T "(·@{~w ········@{~w~^ ~})")
From: Joe Marshall
Subject: [NOISE] Re: toplevel variables in CMUCL, get rid of the SPECIAL declaration!
Date: 
Message-ID: <d7dvv29v.fsf_-_@content-integrity.com>
Erik Naggum <····@naggum.net> writes:

>   But those who have got Perl, well, you can't pry it loose from
>   their dead cold fingers, either.

Brer Rabbit couldn't let go of the tar baby, either.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----
From: ······@corporate-world.lisp.de
Subject: Re: toplevel variables in CMUCL, get rid of the SPECIAL declaration!
Date: 
Message-ID: <93kms0$9mg$1@nnrp1.deja.com>
In article <··············@lambda.jesus.cam.ac.uk>,
  Christophe Rhodes <·····@cam.ac.uk> wrote:

> Can you give an example of when shadowing a global lexical variable is
> useful? I really haven't yet come across a use for this, though I
> grant you that I haven't been programming in lisp for as long as most
> readers here.

I'm surprised to see this question. If I have a global I/X/Y/Z/FOO
and also local I/X/Y/Z/FOO, this doesn't mean I want dynamic
binding for those - they just happen to have the same name.

> Basically, I would guess that no-one actually does
> (setf foo 'bar)
> at top-level in a lisp file. Sure, we would at the top-level
> interaction loop, while we're testing things, but I would guess not in
> a real application (please correct me if I'm wrong).

Look at something like a Lisp Machine, the top-level loop is
your shell and the thing runs real applications. From
there you could derive several similar scenarios.

> I suppose I just can't see why we'd want a global lexical variable;
> can anyone enlighten me on this?

But you see the difference it makes?

I just want:

- global variables
- that global variables are not necessarily declared special
- that global variables are not accidentally get declared
  special, because somebody did not understand the semantics
- a consistent behaviour for such a basic mechanism accross
  the popular Lisp implementations


Sent via Deja.com
http://www.deja.com/
From: Barry Margolin
Subject: Re: toplevel variables in CMUCL, get rid of the SPECIAL declaration!
Date: 
Message-ID: <aYn76.17$IL1.66@burlma1-snr2>
In article <············@nnrp1.deja.com>,
 <······@corporate-world.lisp.de> wrote:
>I just want:
>
>- global variables
>- that global variables are not necessarily declared special
>- that global variables are not accidentally get declared
>  special, because somebody did not understand the semantics
>- a consistent behaviour for such a basic mechanism accross
>  the popular Lisp implementations

Sorry, Common Lisp doesn't have global, non-special variables.  CLTL2 says
that if a variable reference occurs outside a construct that creates a
lexical binding, it's taken to refer to the special variable.  I can't find
the analogous statement in the standard, but I expect it's in there
someplace.

However, implementations have interpreted that "refer to the special
variable" specification differently.  Most act as if the referring form
were wrapped in (locally (declare (special <variable>)) ...) so that just
that access is to the special variable.  CMUCL has interpreted it to mean
that the variable should be proclaimed special (i.e. you forgot to DEFVAR
it).

-- 
Barry Margolin, ······@genuity.net
Genuity, 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: Rainer Joswig
Subject: Re: toplevel variables in CMUCL, get rid of the SPECIAL declaration!
Date: 
Message-ID: <joswig-E42E75.22243711012001@news.is-europe.net>
In article <···············@burlma1-snr2>, Barry Margolin 
<······@genuity.net> wrote:

> However, implementations have interpreted that "refer to the special
> variable" specification differently.  Most act as if the referring form
> were wrapped in (locally (declare (special <variable>)) ...) so that just
> that access is to the special variable.  CMUCL has interpreted it to mean
> that the variable should be proclaimed special (i.e. you forgot to DEFVAR
> it).

That's what I want: a common behaviour across all implementations
for such a basic issue (introducing variables via SETF/SETQ).
Even better when the standard is worded/defined/whatever
such that it describes/defines what most
Lisp systems do. CMUCL clearly behaves differently
than, say, MCL in this respect. And I don't like the way
CMUCL "interprets" the standard. This is a possible source
for confusion and errors.

-- 
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Rob Warnock
Subject: Re: toplevel variables in CMUCL, get rid of the SPECIAL declaration!
Date: 
Message-ID: <93po3b$nijjl$1@fido.engr.sgi.com>
Barry Margolin  <······@genuity.net> wrote:
+---------------
|  <······@corporate-world.lisp.de> wrote:
| >I just want:
| >- that global variables are not necessarily declared special
| 
| Sorry, Common Lisp doesn't have global, non-special variables.  CLTL2 says
| that if a variable reference occurs outside a construct that creates a
| lexical binding, it's taken to refer to the special variable.  I can't find
| the analogous statement in the standard, but I expect it's in there
| someplace.
+---------------

Well, the CLHS glossary says:

	global variable n. a dynamic variable or a constant variable.

	lexical variable n. a variable the binding for which is in the
	    lexical environment. 

	lexical environment n. that part of the environment that contains
	    bindings whose names have lexical scope.

That's a big hint, but I think this[*] nails it:

	3.1.2.1.1 Symbols as Forms
	If a form is a symbol, then it is either a symbol macro or a variable.
	...
	If a form is a symbol that is not a symbol macro, then it is the
	name of a variable, and the value of that variable is returned.
[*]==>	There are three kinds of variables: lexical variables, dynamic
	variables, and constant variables.

So if a variable *ever* exists when it's not lexically bound, then it's
either dynamic (special) or constant. And once special, always special,
even when subsequently bound. I take that as saying that all (non-constant)
globals are special.


-Rob

p.s. Are constant variables special?  Well, it doesn't matter whether
they are or not, since binding one isn't allowed. "3.1.2.1.1.3 Constant
Variables" says:

	The consequences are undefined if an attempt is made to assign a
	value to, or create a binding for a constant variable...

and "Macro DEFCONSTANT" says:

	The consequences are undefined when constant symbols are rebound as
	either lexical or dynamic variables. In other words, a reference to
	a symbol declared with defconstant always refers to its global value.

and issue "DEFCONSTANT-SPECIAL:NO" ("DEFCONSTANT-SPECIAL:DOESNT-MATTER",
as passed) says it even more strongly:

	Clarify that it is an error to rebind constant symbols as either
	lexical or special variables.  (In other words, a reference to a
	symbol declared with DEFCONSTANT always refers to its global value.)

-----
Rob Warnock, 31-2-510		····@sgi.com
SGI Network Engineering		http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy.		Phone: 650-933-1673
Mountain View, CA  94043	PP-ASEL-IA