[armedbear-devel] Symbol-macro patch

[Alessio Stalla]

On Wed, Nov 2, 2011 at 9:40 PM, Erik Huelsmann <ehuels at gmail.com> wrote:
> 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.

That's very good, thanks.

> 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?

I added a field out of pure convenience. Symbol macros are implemented
in Java, and it's easier to use a field than a property on the plist.
Actually, an added field wastes more memory than a property, since
most symbols don't name a symbol macro. I don't think that's a
problem, since the number of symbols in an image should generally be
limited to a few thousands. Anyway, I don't see compelling reasons to
change where SETF functions are stored.

Bye,
Alessio