On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla alessiostalla@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