[fset-devel] FSet on ABCL
Scott L. Burson
Scott at sympoiesis.com
Wed Oct 26 21:41:58 UTC 2011
On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla
<alessiostalla at gmail.com> wrote:
> Greetings,
>
> as part of my nth plan to conquer the world (which of course I won't
> unveil right now), I tried FSet on ABCL. I managed to make it run, but
> I had to patch it; you can find the patch attached (it's taken against
> the version in Quicklisp, but I believe it's the latest version).
Thanks for the patch!
Did you run the test suite? Were any non-default JVM settings
required, e.g. stack size?
Do you have any performance comparisons (of FSet operations in
particular) vis-a-vis, say, SBCL?
> Besides some minor #+abcl porting stuff, the one thing that stuck out
> was the DEFLEX macro for defining global lexical variables, which
> conflicts with ABCL's implementation of symbol macros.
> (deflex var) expands basically into (define-symbol-macro var
> (symbol-value 'var)). The problem: ABCL stores symbol macros in the
> value cell of symbols, so you can't have a symbol which is both a
> variable and a symbol macro.
> Now, I believe deflex as written is non portable CL. This is because
> accessing the symbol-value of an unbound variable is, to my
> interpretation, unspecified [*]; and if you use defvar/defparameter
> with var, then you cannot use it as a symbol macro. Thus, I patched it
> (taking inspiration from Rob Warnock's version of deflex/defglobal).
Heh -- I had seen Rob's implementation and wondered why he created a
second symbol. Now I know :-)
> I don't think a symbol for which there is no special declaration in
> scope can be considered to name a dynamic variable, and thus to have a
> value cell at all.
On a strict reading, you're probably correct. But I had never seen an
implementation for which this was not the case.
-- Scott
More information about the fset-devel
mailing list