Robert Munyer's incessant bickering has made me realize it was a mistake to
try to discuss this with him.  I apologize for the spectacle.

I have included, below, Jeff's excellent listing of ANSI statements
regarding variables which are neither declared special nor have a clear
lexical binding.  I wish to:
 1. Sumarize my understanding of the position.
 2. Add one other reference, for the record, and ask a question about
one of Jeff's references.
 3. Raise two issues which all this still leaves me confused about.

1. Summary:

  It is an error for a variable which does not have a lexical binding to
  not be explicitly declared special in some way (such as a declamation
  or local declaration).  "It is an error" has the usual meaning that
  the behavior is not defined.   In this particular case, this means
  that implementations may or may not signal warnings or errors at
  either compile or run time.  No conforming program can rely on
  undeclared variables being special.

It is acknowledged that this makes it difficult to use free variables in
the interpreter.  Because of this, all current implementations happen to
treat undeclared free variables as special, at least in the interpreter.
At least one major implementation, CMUCL, make a global special
declamation for all free variables, whether compiled or interpreted.
This does not conflict with the above, but has the perhaps unfortunate
effect of changing the semantics of otherwise conforming code once some
user has mistakenly referenced an undeclared free variable (in
interpreted or compiled code).

2. References:

Section 3.2.2.3 Semantic Constraints, says:

  All conforming programs must obey the following constraints, which are
designed to minimize the observable differences between compiled and  
  interpreted programs:
  ...
  Special proclamations for dynamic variables must be made in the  
  compilation environment. Any binding for which there is no special  
  declaration or proclamation in the compilation environment is treated
  by the compiler as a lexical binding.

At first glance, one might think this contradicts the above, but I
interpret this is specifying that the compiler must assume the variable
is lexical and look for a lexical binding.  It is then, presumably, "an
error", when a compiler tries to look up a lexical binding and doesn't
find one.

Question:  Jeff quoted an X3J13 issue called "PROCLAIM LEXICAL", noting
that the wording of the issue was changed over time.  I cannot find an
issue with this name in Kent's excellent HyperSpec.  Is it there?  Can
someone give me a pointer to it?

3. Outstanding issues:

 I. Once a variable has been declaimed special, how does one make it
unspecial?   (Do I need to clarify why I think this is important?)

 II. Consider the following:
   (let ((x 1)) (compile 'foo '(lambda () x)))

I feel that on the one hand, the reference to x in the lambda is not a
variable refering to the binding of the lexical variable, but simply the
symbol x in a quoted list that happens to begin with the word lambda.
The list is not a "lambda expression".  On the other hand, the
definition of COMPILE specifically says that it IS a lambda expression.
Also, this list must be compiled in the compilation environment.   The
end of section 3.2.1 Compiler Terminology says that COMPILE is a
run-time compiler for which the run-time environment and compiler
startup environment are the same, and that the compilation environment
inherits (ultimately) from the compiler startup environment.  Since the
run-time environment in which compile was called clearly had a lexical
binding for X, this is also true in the compilation environment.

The dictionary defintion for COMPILE says that the lambda expression is
coerced to a function, and coercing a lambda-expression to a function in
the body of the LET would also ordinarily enclose the binding of X.

It then goes on to say, though, that:
  The consequences are undefined if the lexical environment surrounding
  the function to be compiled contains any bindings other than those for
  macros, symbol macros, or declarations.

Since this is the most specific statement, it takes precedence.
However, I would feel more comfortable if there was some acknowledgement
that the second argument to COMPILE was not a full fledged lambda
expression and that its coercion to a funciton did not follow the usual
semantics regarding the capture of lexical bindings.

I note that since the consequence of this case are undefined, it does
leave open the possibility that an implemenation might make use of the
lexical binding.  Of course, no conforming program could rely on this
extension, and it raises another issue.  If the compiler can reference
lexical bindings in a run-time environment outside the scope of the
compiler, then the reference I cite above (section 2) would want to be
handled by such implementations by doing a run-time lexical variable
lookup, as though in an interpreter.  This, in turn, raises the issue of
run-time maniplulation of environments by user code.  While it seems
that "madness this way lies", I could imagine wanting to use a debugger
in which the lexical (and dynamic?) environment from the current stack
frame were available to me in evaluating forms within the debugger.  (I
remember being shocked as freshman that this was NOT what happened.) One
might make use of some of these features to write such a debugger.

So, the question is:  Is this analysis correct?  Is the behavior of
undeclared non-lexical variables undefined, and does this include X in
the COMPILE example? Is an implementation free to define the behavior
consistent with the concept of looking (at run or compile time) for a
lexical variable and using it, and failing that, to silently use the
global value?

-h
---------------------------------------------------------

# Note to comp.lang.lisp subscribers:  Sorry, no good technical
# stuff in this one.  Hopefully this is the end of the flame war.

In article <3050113682968...@arcana.naggum.no>,

My own experience is a case in point.  I didn't make any disparaging
statements about you until after you wrote three articles against
me.  You "corrected" me once, and then attacked me several times,
in articles which grew increasingly condescending and sarcastic --
all because I made use of an aspect of Common Lisp that you didn't
understand, in an article that wasn't even directed at you.

Barry Margolin has also accused me of being wrong in this thread,
but he managed to do it without being rude, condescending, snide,
sarcastic, and evasive.  So I can still have a polite debate with
him, and not have to waste my time in flame wars.  You should look
through his articles, and take a lesson.  Maybe then you will not
end up convincing any more people that you are a "pig."

I hope your first sentence above means that you are going to get
out of this thread, and let the rest of us discuss technical issues
in peace.

# Note to subscribers: this article is long, but it's 99% flame free.

In article <DwrDLA....@cogsci.ed.ac.uk>,

    (defun foo () x)

is replaced with

    (defun foo () (declare (special x)) x)

rather than with

    (declaim (special x))
    (defun foo () x)

    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.

Apparently you have a CMU CL handy.  If so, could you please use
it to evaluate the following:

    (let ((data '((       defparameter (defparameter x nil))
                  (             defvar (defvar x nil))
                  (                set (set 'x nil))
                  (               setf (setf x nil))
                  ((setf symbol-value) (setf (symbol-value 'x) nil))
                  (               setq (setq x nil)))))
      (let ((does '()) (doesnt '()))
        (dolist (d data)
          (let ((desc (first d)) (form (second d)) (name (gensym)))
            (eval (subst name 'x form))
            (if (eval `(let ((,name t))
                         (declare (ignore-if-unused ,name))
                         (symbol-value ',name)))
              (push desc does)
              (push desc doesnt))))
        (let ((fmt "~&These ~a: ~:[~%~4t[none]~;~:*~{~%~4t~s~}~]"))
          (format t fmt "proclaim special" (nreverse does))
          (format t fmt "do not" (nreverse doesnt)))))

and let us know what it says?  The results should be:

    These proclaim special:
        DEFPARAMETER
        DEFVAR
    These do not:
        SET
        SETF
        (SETF SYMBOL-VALUE)
        SETQ

In fact, since you've used over a dozen Common Lisps, you probably
have several of them handy.  It would be great if you could evaluate
the above code in each of them.  Other people reading this, please
feel free to contribute results from whichever implementation of
Common Lisp you are using.

Otherwise, all hell would break loose.  You could have any kind of
construct producing any kind of side effect, because the standard
very rarely states explicitly that a certain construct will not
have a certain side effect.  It is just taken for granted that only
documented side effects can exist.

Also, any implementation which follows Erik's suggestion, and
proclaims symbols special when not explicitly required to by the
standard, will be unable to evaluate standard example code
successfully.  For example, see the code in the section on EVAL:

    http://www.harlequin.com/books/HyperSpec/Body/fun_eval.html

You can't argue that an implementation is correct, if it can't even
evaluate the code examples in the standard!

In article <32231138.31DFF...@elwoodcorp.com> "Howard R. Stearns" <how...@elwoodcorp.com> writes:

1.  (setf (symbol-value 'x) 100) => 100
2.  (locally (declare (special x)) x) => 100

It's arguable that x has been declared special in line 2,
but it certainly hasn't been in line 1, and I've never seen
even a warning (not even in CMUCL) for such things as line 1.
Yet it's clear from the HyperSpec and CLtL that symbol-value
reads and writes the value of the dynamic (ie, special) variable.
So x must have been special before any declaration or proclamation
had occurred.  (And line 2 is relying on this.)

  (let ((x 1))
    ...)

and there's no special declaration/proclamation in the compilation
env, the x is bound as a lexical variable.

# Note to subscribers: this article is long, but it's 99% flame free.

In article <DwrDLA....@cogsci.ed.ac.uk>,

    (defun foo () x)

is replaced with

    (defun foo () (declare (special x)) x)

rather than with

    (declaim (special x))
    (defun foo () x)

    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.

Apparently you have a CMU CL handy.  If so, could you please use
it to evaluate the following:

    (let ((data '((       defparameter (defparameter x nil))
                  (             defvar (defvar x nil))
                  (                set (set 'x nil))
                  (               setf (setf x nil))
                  ((setf symbol-value) (setf (symbol-value 'x) nil))
                  (               setq (setq x nil)))))
      (let ((does '()) (doesnt '()))
        (dolist (d data)
          (let ((desc (first d)) (form (second d)) (name (gensym)))
            (eval (subst name 'x form))
            (if (eval `(let ((,name t))
                         (declare (ignorable ,name))
                         (symbol-value ',name)))
              (push desc does)
              (push desc doesnt))))
        (let ((fmt "~&These ~a: ~:[~%~4t[none]~;~:*~{~%~4t~s~}~]"))
          (format t fmt "proclaim special" (nreverse does))
          (format t fmt "do not" (nreverse doesnt)))))

and let us know what it says?  The results should be:

    These proclaim special:
        DEFPARAMETER
        DEFVAR
    These do not:
        SET
        SETF
        (SETF SYMBOL-VALUE)
        SETQ

In fact, since you've used over a dozen Common Lisps, you probably
have several of them handy.  It would be great if you could evaluate
the above code in each of them.  Other people reading this, please
feel free to contribute results from whichever implementation of
Common Lisp you are using.

Otherwise, all hell would break loose.  You could have any kind of
construct producing any kind of side effect, because the standard
very rarely states explicitly that a certain construct will not
have a certain side effect.  It is just taken for granted that only
documented side effects can exist.

Also, any implementation which follows Erik's suggestion, and
proclaims symbols special when not explicitly required to by the
standard, will be unable to evaluate standard example code
successfully.  For example, see the code in the section on EVAL:

    http://www.harlequin.com/books/HyperSpec/Body/fun_eval.html

You can't argue that an implementation is correct, if it can't even
evaluate the code examples in the standard!

Robert Munyer, if I ever doubted that you were unreasonable, your last note
has certainly removed any shred of it.  it is abundantly clear that your
purpose now is revenge, rather than any purported "technical" issues.

if you should return to technical discussions, please, try to respect that
those with whom you try to discuss anything technical might want to refer
you to authoritative documents and standards instead of including them in
their replies or paraphrasing them with an added chance of introducing more
confusion.  you strongly suggest that you have higher regard and respect
for USENET contributions than for standards documents, and this is an
attitude so mind-bogglingly irrational that if I come across as saying "you
are stupid, Robert Munyer", it is because that is exactly what I think.

BTW, anonymous references to private communication, ostensibly to avoid
being the one to slander somebody else, is the best evidence yet to be
found on USENET of how low a person can get.  such behavior reveals an
amazingly cavalier attitude to reproducibility of observations and
credibility of conclusions, and points to a fundamental misunderstanding of
how legitimate observations and conclusions are made.  it is no wonder at
all that such a person is incapable of reading a standards document to
learn of the facts of a specification, when he obviously believes that it
furthers his cause to make such pathetic attacks solely on his opponent.
and to have the gall to make the unfounded claim that he wants to discuss
technical issues at the same time is...

you are in fact wrong on your technical points, Robert Munyer.  there is
nothing more than "read the fine manual" to tell you.  since you refuse to
do that, and instead continue to pose irrelevant questions about what
people think or believe, based on your own misunderstood assumptions, what
exactly did you expect to receive?  what would you do with the answers you
got?  would you use them in anonymous references in discussions with your
colleagues that you are somehow correct in your assumptions?  would you at
any one point go and consult the specification to learn how things _should_
have been done, instead doing a Gallup poll on what a representative sample
of the population might think?  standards are written by the best people we
can find.  anybody at all can have opinions.  this is why we have standards
written by experts instead of Gallup polls on USENET every time we wish to
know what Common Lisp, the language, specifies.

and it is true, I find unbridled display of arrogant ignorance to be the
worst aspect of USENET.  and it is true, I do treat people who refuse to
listen to authoritative sources and instead go on to ask _people_ what they
think, as fundamentally misguided and extremely unlikely to produce
anything of reasonable value in a discussion, because they discuss not what
is, but what people believe.

finally, Robert Munyer, you do most emphatically not _have_ to waste your
time in flame wars.  if you _want_ to waste your time in flame wars, that
is your very own choice.  sometimes, it is more effective to shut up than
to continue to make the crux of your argument that somebody else is a
"pig".

you said you had a technical argument.  I'll believe it when I see it.  I
don't think it is possible to have technical discussion with people whose
mission it is to convince the world of their own personal misconceptions,
including, but not limited to meaningless and pathetic slandering of
others.  I think a technical discussion must refer to something that is
impersonal, such as a standard specification for a programming language.

# This one is 100% flame free.

In article <32231138.31DFF...@elwoodcorp.com>,
Howard R. Stearns <how...@elwoodcorp.com> wrote:

If anyone reading this has a CMU CL handy, It would be helpful if
you could use it to evaluate the test code in my 8/28 article
(message id <500t58$...@Mars.mcs.com>, the code that starts with
"(let ((data '((") and let us know what it says.

One is that this paragraph refers to BINDINGS, not to REFERENCES.

The other detail is that you need to interpret your quoted paragraph
in the proper context.  It is not in the part of the standard that
describes variable access rules; it is in the part that describes
the compilation environment.  This section of the standard is
derived from COMPILE-ENVIRONMENT-CONSISTENCY and its purpose is to
say that special declarations, when they are meaningful, must be
available in the compilation environment (rather than in some other
environment) and that they must be available "soon enough" to be
used by the compiler.  Consider this code snippet:

    ? (defun foo () x)
    FOO
    ? (defun bar () (let ((x 5)) (foo)))
    BAR
    ? (proclaim '(special x))
    NIL
    ? (bar)
    5

The purpose of the compilation environment section you quoted is
to explain that the above code, although it might work in an
interpreted Common Lisp, cannot be compiled.  There are two reasons
for this:  (a) PROCLAIM does not make declarations available in
the compilation environment.  You need to either enclose it in
EVAL-WHEN or change it to DECLAIM.  (b) The declaration is not made
"soon enough."  It must be placed BEFORE the definition of BAR.

Notice I did not say that it has to be placed before the definition
of FOO.  FOO does not need the declaration, because FOO does not
create a binding.  FOO's reference to X is automatically special,
with or without a declaration.

If you look back at the standard you will notice that the paragraph
you omitted (and replaced with three periods) says simply that
macros must be defined before they are needed, and that their
definitions must be available in the compilation environment.
Likewise the other paragraph (which you did not omit) says simply
that special declarations must be made before they are needed, and
that they must be available in the compilation environment.

The requirement that special variables must be declared applies
only in situations where a special declaration is meaningful.  In
FOO the declaration would be meaningless so the rule does not apply.
In BAR the rule applies.

(Once again, it seems, the explanation in CLtL2 is a bit clearer
and easier to understand than the newer one in the HyperSpec.)
This is the corresponding text from CLtL2 section 25.1.3:

    X3J13 voted in June 1989 (COMPILE-ENVIRONMENT-CONSISTENCY)  to
    specify what information must be available at compile time for
    correct compilation and what need not be available until run
    time.

    The following information must be present in the compile-time
    environment for a program to be compiled correctly. This
    information need not also be present in the run-time environment.

           In conforming code, macros referenced in the code being
           compiled must have been previously defined in the
           compile-time environment. The compiler must treat as a
           function call any form that is a list whose car is a
           symbol that does not name a macro or special form. (This
           implies that setf methods must also be available at
           compile time.)

           In conforming code, proclamations for special variables
           must be made in the compile-time environment before any
           bindings of those variables are processed by the compiler.
           The compiler must treat any binding of an undeclared
           variable as a lexical binding.

Here is a demonstration:

    (defun special? (sym)
      (check-type sym symbol)
      (eval `(let ((,sym nil))
               (declare (ignorable ,sym))
               (flet ((f () ,sym))
                 (let ((,sym t))
                   (declare (ignorable ,sym))
                   (f))))))

    (setq sym 'x)

    (special? 'x)          => NIL

    (declaim (special x))

    (special? 'x)          => T

    (unintern 'x)

    (special? 'x)          => NIL

    (special? sym)         => T

-- Robert

Jeff Dalton's article (in reply to Howard Stearns) is a good one,
and the points he makes are all correct.  I have just one small
comment to add.

In article <DwuwC6....@cogsci.ed.ac.uk>,

He wasn't attempting to use the word in its more common Usenet
sense (a summary of all the discussion in a thread, or of just the
parts of the thread that have been accepted by all participants).

# No technical content in this one, just flame-war self defense.

Lately nearly all of your words have been devoted to defending the
standard.  That is pointless -- I am not challenging the standard,
nor is anyone else here.  The problem is that your attacks on me
have not been consistent with the standard.  Why aren't you trying
to defend your own articles, rather than the standard itself?

In article <3050210651732...@arcana.naggum.no>,

Haven't you figured out yet that this is how you antagonize people?
You repeat (over and over, like a drone) "you are wrong" yet you
refuse to present evidence or answer legitimate questions.  If this
had been a test in school, I would have had to give you an F,
because you never even filled in the blanks!

Anyway, I haven't looked into the question of whether implementations
can proclaim the variable special.  I'd regard that as a hostile act
in most implementations, because it has a pervasive effect and there's
no way to undo it.  (And if there is a way to undo it, it will be an
implementation-specific way.)

If you put in special declarations, then I think the Standard is
clear, and you can get the "special but not proclaimed special"
behaviour for global variables.  But without the declarations, what
are implementations allowed to do?  That's not so clear, and you have
to look at lots of stuff: what are conforming implementations allowed
to do in various circumstances, and so on.

* (locally (declare (special snib)) (setq snib 10))
10

* (defun sx ()
    (locally (declare (special snib)) snib))
sx

* (let ((snib 30)) (sx))

In: let ((snib 30))
  (let ((snib 30))
    (sx))
Warning: Variable snib defined but never used.

10

These proclaim special:
    defparameter
    defvar
    setf
    setq
These do not:
    set
    (setf symbol-value)

Unfortunately, my understanding of CL is not based on the Standard
but on CLtL I and what happened in X3J13.  I assume the Standard
reflects the intentions of X3J13 (and that I understand those
intentions fairly well), but when it comes to the standard I
can seldom find all the relavant sections without a lot of mousing
around in the HyperSpec, so it's fairly easy for me to miss something.

[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$...@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

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.

|   Well, I'll read the manual, if you say what sections you think are
|   relevant.

in my reply to him in <3049395203874...@arcana.naggum.no>, I wrote:

    for more information on the environments in Common Lisp, see the Common
    Lisp Hyperspec at Harlequin, Inc, section 3.1.1 Introduction to
    Environments.

        http://www.harlequin.com/books/HyperSpec/Body/sec_3-1-1.html

after which Robert argued that the HyperSpec was in conflict with CLtL2,
that he could change a few words to amend his article, and strongly implied
that his purpose was to have _me_ (not the standard, not the language)
distinguish between the behavior of SETQ and DEFVAR at top-level, which I
had already stated very clearly was not defined by the standard.

res ipsa loquitur.

In article <4vlgt1$...@tools.bbnplanet.com>,

* Claim 1.  Use of top-level SETQ to initialize a variable that
    has not been previously declared special is completely acceptable
    in a code example, even if it is not something you would do in
    an actual program.

  * Argument 1.1.  This usage appears in the standard itself.  For
      example see the section on SETQ:

      http://www.harlequin.com/books/HyperSpec/Body/spefor_setq.html

* Claim 2.  It is not acceptable for an implementation to proclaim
    a symbol special merely because its value is initialized by a
    top-level SETQ.

  * Argument 2.1.  Such a proclamation would be a side effect.
      The standard does not say that this side effect exists or
      might exist.  My understanding is that side effects are not
      allowed unless the standard permits them explicitly.

      If side effects were allowed whenever they are not explicitly
      forbidden, all hell would break loose.  Virtually any construct
      could produce virtually any side effect, because the standard
      very rarely states explicitly that a certain construct will
      not have a certain side effect.  Instead, it is taken for
      granted that only documented side effects can exist.

  * Argument 2.2.  The standard itself contains code which (like
      my own 8/18 example) would fail if this proclamation were
      allowed to occur.  Any implementation which produces this
      undocumented side effect will fail to evaluate successfully
      the following code example from the standard:

      From the section on EVAL:
      http://www.harlequin.com/books/HyperSpec/Body/fun_eval.html

        (setq form '(1+ a) a 999) =>  999
        (eval form) =>  1000
        (eval 'form) =>  (1+ A)
        (let ((a '(this would break if eval used local value)))
          (eval form)) =>  1000

      The standard example code above makes it absolutely clear
      that SETQ does not, and must not, proclaim a symbol to be
      special.

In article <3050412036443...@arcana.naggum.no>,

In article <DwwuLA....@cogsci.ed.ac.uk>,

English is fuzzy and imprecise; Lisp is not.  If you read part of
the standard in English, and part of it in Lisp, and you think that
the English part says that the Lisp part is wrong, you had better
try to re-read the English part and see if there's another way you
could possibly interpret it.

In fact, I'd say that's exactly what code examples are for.

Incidentally, David Moon's word "cell" corresponds very closely
with the way I used to like to use the word "variable," before I
found that doing so could cause so much confusion.

Excerpted from Malcolm Chiang Yoen Chan's original
8/14 article <4utk8d$...@net.auckland.ac.nz>:

1> DEFVAR doesn't just define a global variable X; it also declares
2> that all variables X are "special."  A special variable is dynamic
3> rather than lexical, so it bypasses the normal scoping rule.  Look
4> what would happen if you used SETQ rather than DEFVAR, to establish
5> a global variable without declaring it to be special:
6>
7>     ? (setq x 100)
8>     100
9>     ? (let ((x 1)) (eval 'x))
A>     ;Compiler warnings :
B>     ;   Unused lexical variable X, in an anonymous lambda form.
C>     100

On 8/19 I suggested changing "it" in line 5 above to "its name."
In this amended form, and using the definition of "variable" in
the HyperSpec's glossary, the above is correct and expresses the
idea that I meant to express.

But if I were answering Mr. Chan's question today, I would write
the answer differently so it would be less likely to be misunderstood.
I would replace the text in lines 1-5 with something like this:

    DEFVAR doesn't just assign a global value to a symbol; it also
    globally declares that symbol to be "special."  This means that
    from that point onward, all variable bindings and variable
    references using that symbol will be "special," including for
    example the binding created by your (LET ((X 1)) ...) form.
    Special bindings and references are dynamic rather than lexical,
    so they bypass the normal scoping rule.  Look what would happen
    if you used SETQ rather than DEFVAR, to assign 100 as the global
    value of X without globally declaring the symbol X to be special:

I would also add a postscript to explain the problem with CMU CL.
Something like this:

    P. S.  At least one implementation (a version of CMU CL) has
    a non-standard implementation of SETQ and will not produce the
    correct result in that last example.  You can work around the
    problem in a number of ways.  In standard Common Lisp you could
    use any one of these six forms in that last example:

        1. (setq x 100)
        2. (setf x 100)
        3. (set 'x 100)
        4. (setf (symbol-value 'x) 100)
        5. (locally (declare (special x)) (setq x 100))
        6. (locally (declare (special x)) (setf x 100))

    But in at least one version of CMU CL, you could not use #1 or
    #2 and would have to choose one of #3 through #6.

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.)