[armedbear-devel] Symbol-macro patch
Erik Huelsmann
ehuels at gmail.com
Wed Nov 2 20:40:09 UTC 2011
Hi Alessio,
On Wed, Nov 2, 2011 at 8:03 PM, Alessio Stalla <alessiostalla at gmail.com> wrote:
> Greetings,
>
> following up from my earlier mail about FSet and ABCL, I propose a
> patch (attached) to fix ABCL's symbol-macro implementation not to use
> the symbol's global value slot. Local symbol macros still use the same
> storage location as variables, since it's not possible to use
> symbol-value on local variables and it is forbidden to both declare a
> variable special and associate a symbol macro to its name. I also
> simplified some code that did not make use of this assumption, and
> specially handled cases where a symbol was both naming a special
> variable and a symbol macro.
>
> An inconsistency remains:
>
> (defvar foo)
> (define-symbol-macro foo nil)
>
> signals an error, while
>
> (define-symbol-macro foo nil)
> (defvar foo)
>
> does not. This behaviour is present in stock ABCL as well, and
> apparently it's allowed by the ANSI standard, although at least SBCL
> consistently signals an error in both cases. I believe we should do
> so, too. But I think it pertains to another patch.
>
> Please test the patch with your own code; I ran the ANSI test suite
> and got no regressions, but I'm not very confident about it -
> apparently it doesn't cover symbol macros very well or at all, since
> at one time I ran it with define-symbol-macro effectively
> unimplemented and it happily reported the same 19-20 failures it did
> before.
I have some code which quite heavily depends on symbol macros (not
combined with SETF though); I'll test your patch with that.
Also, I see you've added a symbol-macro field to the Symbol class.
We're currently storing SETF functions for the symbol in the plist.
Maybe we should change the storage in the plist to storage in a class
field as well?
Bye,
Erik.
More information about the armedbear-devel
mailing list