Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!news.duq.edu!newsgate.duke.edu!agate!howland.erols.net!vixen.cso.uiuc.edu!chi-news.cic.net!news.compuserve.com!ix.netcom.com!netcom.net.uk!dispatch.news.demon.net!demon!usenet2.news.uk.psi.net!uknet!usenet1.news.uk.psi.net!uknet!uknet!newsfeed.ed.ac.uk!edcogsci!jeff
From: jeff@cogsci.ed.ac.uk (Jeff Dalton)
Subject: Re: EVAL Implementations
Message-ID: <Dx4zn9.2rw.0.macbeth@cogsci.ed.ac.uk>
Organization: HCRC, University of Edinburgh
References: <3050210651732525@arcana.naggum.no> <DwyJo0.154.0.macbeth@cogsci.ed.ac.uk> <3050412036443613@arcana.naggum.no>
Date: Tue, 3 Sep 1996 03:13:56 GMT
Lines: 57

In article <3050412036443613@arcana.naggum.no> Erik Naggum <erik@naggum.no> writes:
>[Jeff Dalton]
>
>|   Could you perhaps say, for me and any others in similar boats, what
>|   technical issue is, as you see it.
>
>the initial technical point I made was that Common Lisp does not make the
>distinction that Robert Munyer said it does in his reply, namely of
>_treating_ foo special in (defvar foo ...) and _not_ special in (setq foo
>...) at top-level.  his exact words from <4v7ifq$976@Mars.mcs.com> were as
>follows:
>
>    DEFVAR doesn't just define a global variable X; it also declares
>    that all variables X are "special."  A special variable is dynamic
>    rather than lexical, so it bypasses the normal scoping rule.  Look
>    what would happen if you used SETQ rather than DEFVAR, to establish
>    a global variable without declaring it to be special:
>
>	? (setq x 100)
>	100
>	? (let ((x 1)) (eval 'x))
>	;Compiler warnings :
>	;   Unused lexical variable X, in an anonymous lambda form.
>	100

There are problems with how RM's point was worded above, but I think
some of the things he said later made it clearer what he was getting
at.  And he's at least partly right.  (DEFVAR X ...) proclaims X
special, which affects all uses (reference, assignment, binding) of X
as a variable -- the `all variables X are "special"' above -- and
you can avoid this pervasive effect by not using DEFVAR.

>I pointed out that the semantics of SETQ at top-level without a special
>declaration is not defined by the language.  and the fact remains, it is
>not defined by the language.  implementations are free to do what they
>want.

Could you say _why_ you think the semantics is not defined and why
that leaves implementations free to do whatever they want?  For
instance, if the standard explicitly said "the consquences are
undefined", or used one of the other phrases defined in the dection
on error terminology, that would make things fairly clear.

But it looks instead like (at most) the standard merely fails to state
the semantics, and I don't know where it says what implementations can
do in such cases.

There are also a number of things in the standard that suggest that
the semantics of top-level SETQ is defined, so that any failure
to explicitly and clearly define it is an oversight.  (I've discussed
some of these in earlier articles and won't repeat the discussion
here.)

(Note for RM: the standard explicitly says that "Examples"
sections are not part of the standard.)

-- jd
