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 <[email protected]> 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 [email protected] http://lists.common-lisp.net/cgi-bin/mailman/listinfo/parenscript-devel
