Hi Alessio,
On Wed, Nov 2, 2011 at 8:03 PM, Alessio Stalla alessiostalla@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.