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).
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). However, I do think ABCL's implementation is very brittle (and probably conflicting with ANSI as well), because if you setf the symbol-value of a symbol with a global symbol macro attached, you remove the symbol macro! So, I think we should fix it for 1.0.1. Perhaps I can do the fix myself, but we better discuss it before because I fear this might be a deep change.
[*] symbol-value ... Accesses the symbol's value cell. [1] value cell n. Trad. (of a symbol) The place which holds the value, if any, of the dynamic variable named by that symbol, and which is accessed by symbol-value. [2] dynamic variable n. a variable the binding for which is in the dynamic environment. [3]
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.
[1] http://www.lispworks.com/documentation/HyperSpec/Body/f_symb_5.htm#symbol-va... [2] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_v.htm#value_cel... [3] http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_d.htm#dynamic_v...
Cheers, Alessio
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
On Wed, Oct 26, 2011 at 5:41 PM, Scott L. Burson Scott@sympoiesis.com wrote:
On Wed, Oct 26, 2011 at 10:12 AM, Alessio Stalla alessiostalla@gmail.com wrote:
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.
I'm not sure a strict reading would have that. Symbols can have value attributes, and value attributes are accessed by symbol-value [1]: "If a symbol has a value attribute, it is said to be bound, and that fact can be detected by the function boundp. The object contained in the value cell of a bound symbol is the value of the global variable named by that symbol, and can be accessed by the function symbol-value. A symbol can be made to be unbound by the function makunbound."
Symbol-value [2] accesses a symbol's value attribute, and it's explicitly mentioned that unbound issues only occur on reads: "Should signal unbound-variable if symbol is unbound and an attempt is made to read its value. (No such error is signaled on an attempt to write its value.) " I'd think, then, that as long as some symbol-value is written first, reading shouldn't be a problem.
The issue with symbol-macros and special variables still stands of course. But I don't think that a symbol needs to be declared as a special variable in order for its symbol-value to be set and read.
//JT
[1] http://www.lispworks.com/documentation/HyperSpec/Body/t_symbol.htm#symbol [2] http://www.lispworks.com/documentation/HyperSpec/Body/f_symb_5.htm#symbol-va...
On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson Scott@sympoiesis.com wrote:
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?
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
Hi,
to follow up on the topic of running FSet on ABCL, I just committed a set of changes to ABCL to modify its implementation of symbol macros. I verified that FSet compiles and loads cleanly with it and without the modifications to deflex that were present in my earlier patch. I also played with FSet a bit (that's the topic for another mail) and everything appears to be working fine. However, I can't run the test suite; I tried (fset::run-test-suite 1) and it inevitably crashes with a stack overflow exception, even if I raise the stack size quite a bit (I went up to 8M from a default which is not clearly documented but is certainly between 512k and 2M). Does the test suite depend on the CL implementation doing tail-call optimization?
Bye, Alessio
On Thu, Oct 27, 2011 at 1:19 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Wed, Oct 26, 2011 at 11:41 PM, Scott L. Burson Scott@sympoiesis.com wrote:
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?
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
On Tue, Nov 8, 2011 at 3:39 PM, Alessio Stalla alessiostalla@gmail.com wrote:
I just committed a set of changes to ABCL to modify its implementation of symbol macros. I verified that FSet compiles and loads cleanly with it and without the modifications to deflex that were present in my earlier patch. I also played with FSet a bit (that's the topic for another mail) and everything appears to be working fine.
Okay, good.
However, I can't run the test suite; I tried (fset::run-test-suite 1) and it inevitably crashes with a stack overflow exception, even if I raise the stack size quite a bit (I went up to 8M from a default which is not clearly documented but is certainly between 512k and 2M). Does the test suite depend on the CL implementation doing tail-call optimization?
Not that I recall -- nor does a quick look at the code reveal any such dependence.
If you can capture a (partial) backtrace, I will take a look at it.
-- Scott
-
Alessio Stalla -
Joshua TAYLOR -
Scott L. Burson