From: David Sletten
Subject: Dynamic variables (part II)
Date: 
Message-ID: <3CEF8E37.6000302@slytobias.com>
This is sort of a follow-up to my question(s) a few weeks ago about 
dynamic variables--

I've seen the comment in books to the effect that it's bad style to 
create a global variable with SETF. Rather, DEFVAR or DEFPARAMETER 
should be used instead. However, I've noticed an implementation-specific 
quirk that suggests there is more than a stylistic difference here.

Consider the following:
(setf pung 'foo)
(defvar bar 'baz)

In CLISP and MCL, PUNG is not a special variable but BAR is. But in 
CMUCL both variables are special. In fact, the SETF in CMUCL generates a 
warning that it's "Declaring PUNG special.".

Touretzky's 'Gentle Introduction' includes an example (pg. 436) that 
relies on the behavior displayed by CLISP/MCL (odd since he's from 
CMU?). This is CLISP:
[41]> (defvar birds)
BIRDS
[42]> (setf birds '(eagle vulture))
(EAGLE VULTURE)
[43]> (describe 'birds)

BIRDS is the symbol BIRDS, lies in #<PACKAGE COMMON-LISP-USER>, is 
accessible in the package COMMON-LISP-USER, a variable declared SPECIAL, 
value: (EAGLE VULTURE).

  #<PACKAGE COMMON-LISP-USER> is the package named COMMON-LISP-USER. It 
has the nicknames CL-USER, USER.
  It imports the external symbols of the packages COMMON-LISP, EXT and 
exports no symbols, but no package uses these exports.

  (EAGLE VULTURE) is a list of length 2.

[44]> (setf fish '(salmon tuna))
(SALMON TUNA)
[45]> (describe 'fish)

FISH is the symbol FISH, lies in #<PACKAGE COMMON-LISP-USER>, is 
accessible in the package COMMON-LISP-USER, a variable, value: (SALMON 
TUNA).

  #<PACKAGE COMMON-LISP-USER> is the package named COMMON-LISP-USER. It 
has the nicknames CL-USER, USER.
  It imports the external symbols of the packages COMMON-LISP, EXT and 
exports no symbols, but no package uses these exports.

  (SALMON TUNA) is a list of length 2.

[46]> (defun ref-fish () fish)
REF-FISH
[47]> (defun ref-birds () birds)
REF-BIRDS
[48]> (ref-fish)
(SALMON TUNA)
[49]> (ref-birds)
(EAGLE VULTURE)
[50]> (defun test-lexical (fish) (list fish (ref-fish)))
TEST-LEXICAL
[51]> (test-lexical '(guppy minnow))
((GUPPY MINNOW) (SALMON TUNA))
[52]> (defun test-dynamic (birds) (list birds (ref-birds)))
TEST-DYNAMIC
[53]> (test-dynamic '(robin sparrow))
((ROBIN SPARROW) (ROBIN SPARROW))

The CLHS entry for SETF doesn't mention this issue one way or the other. 
Can anyone please clarify this?

Thanks,
David Sletten

From: Coby Beck
Subject: Re: Dynamic variables (part II)
Date: 
Message-ID: <XoQH8.48306$Ka.3580670@news2.calgary.shaw.ca>
"David Sletten" <·····@slytobias.com> wrote in message
·····················@slytobias.com...
> This is sort of a follow-up to my question(s) a few weeks ago about
> dynamic variables--
>
> I've seen the comment in books to the effect that it's bad style to
> create a global variable with SETF. Rather, DEFVAR or DEFPARAMETER
> should be used instead. However, I've noticed an implementation-specific
> quirk that suggests there is more than a stylistic difference here.

It is more than bad style, it is bad programming.

[snip code]
> The CLHS entry for SETF doesn't mention this issue one way or the other.
> Can anyone please clarify this?

I won't check where, but it does say in there somewhere that the effects of
creating a variable with setf are undefined.

--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
From: David Sletten
Subject: Re: Dynamic variables (part II)
Date: 
Message-ID: <3CF03F1F.2020402@slytobias.com>
Coby Beck wrote:


> 
>>The CLHS entry for SETF doesn't mention this issue one way or the other.
>>Can anyone please clarify this?
>>
> 
> I won't check where, but it does say in there somewhere that the effects of
> creating a variable with setf are undefined.
> 
OK, thanks. I'll look more closely at the HyperSpec. This does of course undermine the example that Touretzky uses in his book.


David Sletten
From: Pierre R. Mai
Subject: Re: Dynamic variables (part II)
Date: 
Message-ID: <87sn4ezw4y.fsf@orion.bln.pmsf.de>
David Sletten <·····@slytobias.com> writes:

> Coby Beck wrote:
> 
> 
> >
> 
> >>The CLHS entry for SETF doesn't mention this issue one way or the other.
> >>Can anyone please clarify this?
> >>
> > I won't check where, but it does say in there somewhere that the
> > effects of
> 
> > creating a variable with setf are undefined.
> >
> 
> OK, thanks. I'll look more closely at the HyperSpec. This does of course undermine the example that Touretzky uses in his book.

FWIW, CMUCL's behaviour can be tuned by adjusting the special variable
ext:*top-level-auto-declare*:

* (describe 'ext:*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.

Regs, Pierre.

-- 
Pierre R. Mai <····@acm.org>                    http://www.pmsf.de/pmai/
 The most likely way for the world to be destroyed, most experts agree,
 is by accident. That's where we come in; we're computer professionals.
 We cause accidents.                           -- Nathaniel Borenstein