[Openmcl-devel] local special on symbol-macro
Tobias C. Rittweiler
tcr at freebits.de
Thu Oct 22 02:52:21 PDT 2009
Gary Byers writes:
> 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.
I completely concur.
> > 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 ?
> ...)
Sure. I didn't speak of the case of bound declarations, but still of my
example as quoted above. There are implementations which signal an error
on my example. (They probably didn't realize that the paragraph about
erroring on special declarations in the dictionary entry of
SYMBOL-MACROLET specifies behaviour for bound declarations only.)
> > 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"
I'm sorry I silenty changed my hat from language lawyer to user. Yes,
the consequences are unspecified; as a user, I'd like my implementation
to signal an error in this particular case, though.
> >
> > 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.)
Yes, it should have been (LOCALLY (DECLARE (SPECIAL .FOO.)) .FOO.).
Thanks for your reply, and thanks for taking care of the issue,
-T.
More information about the Openmcl-devel
mailing list