[fset-devel] FSet on ABCL

[Alessio Stalla]

On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson <Scott at sympoiesis.com> wrote:
> 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?

I haven't run the test suite yet, nor made any performance
comparisons. Regarding JVM settings, in order to compile and load FSet
(under SLIME) I had to increase the maximum heap size from the (iirc)
64M default. I set it at 256M but it may well be that a lower value is
sufficient. In the next few days I'll do a few tests and benchmarks
and I'll keep you informed on the results.

>
>> 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 particularly like the second interned symbol solution... I
tried initially with a gensym, but it's hard to get right the
interplay between compile-time, load time, and the file compiler
possibly losing gensym identity, so I guess Rob's approach is the most
practical.

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

Yes, me neither, and I'd like to get ABCL fixed in that regard. You
might keep your implementation of deflex as-is; in the meantime I will
use my patched version, until ABCL is fixed.

Thanks,
Alessio