[Openmcl-devel] local special on symbol-macro

Gary Byers gb at clozure.com
Wed Oct 21 18:42:48 PDT 2009



On Mon, 19 Oct 2009, Tobias C. Rittweiler wrote:

>
> I think the following
>
>  (let ((x :special))
>    (declare (special x))
>    (symbol-macrolet ((x :symbol-macro))
>      (values x (locally (declare (special x)) x))))
>
> should return
>
>  :SYMBOL-MACRO, :SPECIAL
>
> It currently returns
>
>  :SYMBOL-MACRO, :SYMBOL-MACRO

Section 3.1.2.1.1 (everyone's favorite section !) uses some
unfortunate language which seems to suggest that symbol-macro
definitions aren't subject to shadowing - "... if there is a binding of
the symbol as a symbol-macro ..." rather than something like "... if
there is an unshadowed binding ..." -  but the dictionary entry for
SYMBOL-MACROLET explictly discusses the notion that bindings established
by SYMBOL-MACROLET are indeed subject to shadowing amd are visible whenever
lexical bindings of the symbol would be visible (e.g., not visible in cases
like your example).  That seeming contradiction leaves a little bit of
somewhat reasonable doubt as to what the spec actually says, but I think
that I agree with you based on a preponderance of evidence.

>
> SBCL and CLISP return :SYMBOL-MACRO, :SPECIAL, while others signal an
> error. I think, signalling an error is a mistake, and I'll mention this
> issue to those implementations.
>
> The reasoning why I think :SYMBOL-MACRO, :SPECIAL is the correct
> implementation (and erroring is not) is mostly because
>
>  http://www.lispworks.com/documentation/HyperSpec/Issues/iss228_w.htm
>
> says so. I couldn't find it spelled out as explicitly in the spec
> itself. Perhaps you're more lucky than me.

I don't find the "not erroring" part controversial; I read the spec as
saying that a "bound" special declaration for a symbol-macro is required
to signal an error:

(symbol-macrolet ((foo :foo))
   (declare (special foo))       ; Huh ?
   ...)

I think that there are a lot of (well, at least something on the order
of 10) cases where the spec as written and cleanup issues as passed
seem to contradict each other.   The spec's binding and the cleanup
issues aren't, but when the spec seems to contradict itself I don't
see much of a problem with using X3J13 issue discussions as a tiebreaker.
(I'm not 100% sure that 3.1.2.1.1 and the SYMBOL-MACROLET entry contradict
each other, but I do find the language in 3.1.2.1.1 ... unfortunate, since
it really seems to be saying something different.)

>
>
> There's some inconsistency at place here, though, because
> the definition of DEFINE-SYMBOL-MACRO explicitly forbids declaring a
> global symbol macro to be special.
>
> So the following _should_ signal an error:
>
>  (progn (define-symbol-macro .foo. :global-symbol-macro)
>         (locally (declare (special .foo.)) .foo.))
>
> (CCL returns :GLOBAL-SYMBOL-MACRO)
>
> or
>
>  (progn (define-symbol-macro .foo. :global-symbol-macro)
>         (proclaim '(special .foo.)))

Um, the only thing that I can see that describes this situation
is (from the DEFINE-SYMBOL-MACRO entry):

"The consequences are unspecified if a special declaration is made for
symbol while in the scope of this definition (i.e., when it is not
shadowed[2] by a binding for a variable or symbol macro named by the
same symbol)."

I don't see anything that requires that this case signal an error;
unspecified consequences are supposed to be "unpredictable but harmless"

>
> On the other hand,
>
>    (progn (define-symbol-macro .foo. :global-symbol-macro)
>           (let ((.foo. :special))
>             (declare (special .foo.))
>             (values .foo.
>                     (let ((.foo. :lexical))
>                       (locally (declare (special .foo.)))))))
>
> should _not_ signal an error, but return :SPECIAL, :SPECIAL.

I think that there's a typo in your example, isn't there ?  (The second arg
in the VALUES call sure looks to me like it should return NIL.)


>
>  -T.
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>



More information about the Openmcl-devel mailing list