Hi,
This week, Alessio Stalla and I are trying to get Parenscript to compile on ABCL. We're using Parenscript 2.3 as distributed with Quicklisp.
Parenscript 2.2 worked fine, after fixing a potential readtables issue. However, Parenscript 2.3 fails compilation during the compilation of the (DEFINE-EXPRESSION-OPERATOR LET # ...) toplevel form.
The problem is that it generates an expression (VAR X), which is then expanded to (DEFPARAMETER X). However, that's non-conforming because the initial value is required according to the CLHS. Looking at the definition of the VAR macro, I see the problem:
(defmacro VAR (name &optional value docstring) `(defparameter ,name ,@(when value (list value)) ...))
can indeed lead to a (DEFPAMETER X)
I haven't found out if/why this isn't a problem on Parenscript 2.2 or why Parenscript 2.3 would cleanly compile on SBCL, because - like ABCL - it rejects forms like that.
If it is ABCL that's broken here, could you help us fix it? If not, could you fix parenscript to work on ABCL?
I'm eager to learn about your analysis of the situation. If you need help on settin up ABCL, I'll gladly provide it.
Bye,
Erik
Hi all,
After a night's sleep, I found the problem in ABCL this morning: the LET operator expression definer has a function called VAR, which is also a macro. This confuses ABCL. We'll fix that. Parenscript will compile nicely after that.
The point that the VAR macro may expand to non-conforming code remains, however.
Bye,
Erik.
On Sat, Aug 20, 2011 at 10:00 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi,
This week, Alessio Stalla and I are trying to get Parenscript to compile on ABCL. We're using Parenscript 2.3 as distributed with Quicklisp.
Parenscript 2.2 worked fine, after fixing a potential readtables issue. However, Parenscript 2.3 fails compilation during the compilation of the (DEFINE-EXPRESSION-OPERATOR LET # ...) toplevel form.
The problem is that it generates an expression (VAR X), which is then expanded to (DEFPARAMETER X). However, that's non-conforming because the initial value is required according to the CLHS. Looking at the definition of the VAR macro, I see the problem:
(defmacro VAR (name &optional value docstring) `(defparameter ,name ,@(when value (list value)) ...))
can indeed lead to a (DEFPAMETER X)
I haven't found out if/why this isn't a problem on Parenscript 2.2 or why Parenscript 2.3 would cleanly compile on SBCL, because - like ABCL - it rejects forms like that.
If it is ABCL that's broken here, could you help us fix it? If not, could you fix parenscript to work on ABCL?
I'm eager to learn about your analysis of the situation. If you need help on settin up ABCL, I'll gladly provide it.
Bye,
Erik
Thanks for the bug report! I've pushed a fix for the erroneous defparameter to the repository.
I haven't tried Parenscript in ABCL yet, although it is something I meant to do eventually.
Vladimir
On Sun, Aug 21, 2011 at 4:50 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi all, After a night's sleep, I found the problem in ABCL this morning: the LET operator expression definer has a function called VAR, which is also a macro. This confuses ABCL. We'll fix that. Parenscript will compile nicely after that. The point that the VAR macro may expand to non-conforming code remains, however. Bye,
Erik.
On Sat, Aug 20, 2011 at 10:00 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi, This week, Alessio Stalla and I are trying to get Parenscript to compile on ABCL. We're using Parenscript 2.3 as distributed with Quicklisp. Parenscript 2.2 worked fine, after fixing a potential readtables issue. However, Parenscript 2.3 fails compilation during the compilation of the (DEFINE-EXPRESSION-OPERATOR LET # ...) toplevel form. The problem is that it generates an expression (VAR X), which is then expanded to (DEFPARAMETER X). However, that's non-conforming because the initial value is required according to the CLHS. Looking at the definition of the VAR macro, I see the problem: (defmacro VAR (name &optional value docstring) `(defparameter ,name ,@(when value (list value)) ...)) can indeed lead to a (DEFPAMETER X)
I haven't found out if/why this isn't a problem on Parenscript 2.2 or why Parenscript 2.3 would cleanly compile on SBCL, because - like ABCL - it rejects forms like that.
If it is ABCL that's broken here, could you help us fix it? If not, could you fix parenscript to work on ABCL? I'm eager to learn about your analysis of the situation. If you need help on settin up ABCL, I'll gladly provide it.
Bye, Erik
parenscript-devel mailing list parenscript-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
parenscript-devel@common-lisp.net
-
Erik Huelsmann -
Vladimir Sedach