Hi,
I've written a combinator parsing-based set of macros, and successfuly
used it and to write a program for my needs. During the development, I
used OpenMCL, which worked fine. Unfortunately, the only other LISP
implementation available to me that works with my macros is LispWorks;
CMUCL says "attempt to reference undumpable constant" during execution,
and CLISP says
Compiling file /Users/dvd/Workplace/Davidashen/QST/cnc-lesy.lisp ...
*** - COMMON-LISP::PRINT: Despite COMMON-LISP::*PRINT-READABLY*,
#<CLOSURE :LAMBDA (#:L)
(COMMON-LISP::LABELS
((#:STEP (#:L #:RL)
(COMMON-LISP::LET
((#:R
(COMMON-LISP::FUNCALL
(LL-PARSING::PARSE-OR (CNC-LESY::SCAN-NAME)
(CNC-LESY::SCAN-NUMBER)
(LL-PARSING::PARCALL #'LL-PARSING::P-CHAR-CLASS
'(#\( #\) #\[ #\] #\,))
(CNC-LESY::SCAN-SPACE))
#:L)))
(COMMON-LISP::IF (LL-PARSING::SUCCESSP #:R)
(#:STEP (COMMON-LISP::REST #:R)
(COMMON-LISP::APPEND #:RL (LL-PARSING::RESULT #:R)))
(LL-PARSING::RETURN-SUCCESS #:RL #:L)))))
(#:STEP #:L COMMON-LISP::NIL))
> cannot be printed readably.
SBCL just fails with internal error.
The macros are complex, but it is what the macros are for, in the end.
I can live without CMUCL, but would love to make it run under CLISP.
Where to look?
David
From: Sam Steingold
Subject: Re: OpenMCL and LispWorks work, CLISP and CMUCL fail on macros
Date:
Message-ID: <uy8c7zchm.fsf@gnu.org>
> * ············@gmail.com <············@tznvy.pbz> [2005-03-28 12:51:32 -0800]:
>
> I've written a combinator parsing-based set of macros, and successfuly
> used it and to write a program for my needs. During the development, I
> used OpenMCL, which worked fine. Unfortunately, the only other LISP
> implementation available to me that works with my macros is LispWorks;
> CMUCL says "attempt to reference undumpable constant" during
> execution, and CLISP says
>
>
> Compiling file /Users/dvd/Workplace/Davidashen/QST/cnc-lesy.lisp ...
> *** - COMMON-LISP::PRINT: Despite COMMON-LISP::*PRINT-READABLY*,
> #<CLOSURE :LAMBDA (#:L)
> (COMMON-LISP::LABELS
> ((#:STEP (#:L #:RL)
> (COMMON-LISP::LET
> ((#:R
> (COMMON-LISP::FUNCALL
> (LL-PARSING::PARSE-OR (CNC-LESY::SCAN-NAME)
> (CNC-LESY::SCAN-NUMBER)
> (LL-PARSING::PARCALL #'LL-PARSING::P-CHAR-CLASS
> '(#\( #\) #\[ #\] #\,))
> (CNC-LESY::SCAN-SPACE))
> #:L)))
> (COMMON-LISP::IF (LL-PARSING::SUCCESSP #:R)
> (#:STEP (COMMON-LISP::REST #:R)
> (COMMON-LISP::APPEND #:RL (LL-PARSING::RESULT #:R)))
> (LL-PARSING::RETURN-SUCCESS #:RL #:L)))))
> (#:STEP #:L COMMON-LISP::NIL))
>> cannot be printed readably.
>
> SBCL just fails with internal error.
>
> The macros are complex, but it is what the macros are for, in the end.
> I can live without CMUCL, but would love to make it run under CLISP.
> Where to look?
The CLISP error is pretty much equivalent to the CMUCL one.
What happens is that you are trying to write an interpreted function
(closure) into a FAS (compiled) file which neither CLISP nor CMUCL can
do (but, apparently, both MCL and LW can).
I don't think this is a violation of ANSI. More importantly, I think
this problem is indicative of a deeper problem in _your_ code. Why
would you want to save an _interpreted_ closure into a _compiled_ file?
This error means that you either "have an extra quote" and prevent this
closure from being automatically compiled (compiled closures can be
written to a compiled file), or you are "missing a quote" and the lambda
expression (a lambda expression, i.e., a cons cell, can also be written
to a compiled file) is being coerced to a closure prematurely.
At any rate, while explicitly compiling the closure will solve your
immediate portability problem, I urge you to figure out how to avoid that.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.honestreporting.com> <http://www.mideasttruth.com/>
<http://www.openvotingconsortium.org/> <http://www.camera.org>
Abandon all hope, all ye who press Enter.
More importantly, I think
> this problem is indicative of a deeper problem in _your_ code. Why
> would you want to save an _interpreted_ closure into a _compiled_
file?
Indeed it is my error; I just wanted to figure out where to dig; I've
found and fixed.
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: OpenMCL and LispWorks work, CLISP and CMUCL fail on macros
Date:
Message-ID: <87u0mvwkjf.fsf@qrnik.zagroda>
·············@gmail.com" <············@gmail.com> writes:
> CMUCL says "attempt to reference undumpable constant" during execution,
> and CLISP says
>
> Compiling file /Users/dvd/Workplace/Davidashen/QST/cnc-lesy.lisp ...
> *** - COMMON-LISP::PRINT: Despite COMMON-LISP::*PRINT-READABLY*,
> #<CLOSURE :LAMBDA (#:L)
I guess the macro attempts to return a function object instead of
source code. Perhaps a quote is missing before the lambda.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > CMUCL says "attempt to reference undumpable constant" during
execution,
> > and CLISP says
> >
> > Compiling file /Users/dvd/Workplace/Davidashen/QST/cnc-lesy.lisp
...
> > *** - COMMON-LISP::PRINT: Despite COMMON-LISP::*PRINT-READABLY*,
> > #<CLOSURE :LAMBDA (#:L)
>
> I guess the macro attempts to return a function object instead of
> source code. Perhaps a quote is missing before the lambda.
How does it work under both OpenMCL and LispWorks then?
David
> I guess the macro attempts to return a function object instead of
> source code. Perhaps a quote is missing before the lambda.
Found and fixed; but still don't understand why what I wrote is not
valid and why both LW and OpenMCL didn't complain. Thank you for the
hint.
From: Christophe Rhodes
Subject: Re: OpenMCL and LispWorks work, CLISP and CMUCL fail on macros
Date:
Message-ID: <sqd5tjzchq.fsf@cam.ac.uk>
·············@gmail.com" <············@gmail.com> writes:
>> I guess the macro attempts to return a function object instead of
>> source code. Perhaps a quote is missing before the lambda.
>
> Found and fixed; but still don't understand why what I wrote is not
> valid and why both LW and OpenMCL didn't complain. Thank you for the
> hint.
What you wrote is not valid because you attempted to externalise a
literal function: see CLHS 3.2.4.1 and surrounding material. LW and
OpenMCL might have ways of constructing, in some circumstances,
similar literal functions to ones which were file compiled.
Christophe
> Found and fixed; but still don't understand why what I wrote is not
> valid and why both LW and OpenMCL didn't complain.
Consider
(defmacro define-a-function (name)
`(defparameter ,name ',#'list))
and later
(define-a-function *function*)
This code is perfectly correct when interpreted. It defines the
special variable *FUNCTION* to be the value of the function LIST.
Now consider what happens when you compile this code. The file
compiler expands the call to DEFINE-A-FUNCTION, and puts a literal
function object in the code. Then, it tries tu fasdump the function
object.
According to one of the most illegible sections of the ANSI Common
Lisp Standard (affectionaly known as the 'spec around here), a
compliant implementation need not be able to fasdump function objects.
As you've noticed, some are, some aren't.
One possible solution -- depending on what you're trying to achieve --
is to delay the construction of the function object until load time.
(defmacro define-a-function (name)
`(defparameter ,name '#'list))
(Thanks to Bruno Haible for explaining this stuff to me.)
Juliusz
From: Pascal Costanza
Subject: Re: OpenMCL and LispWorks work, CLISP and CMUCL fail on macros
Date:
Message-ID: <3asfneF6bgl82U1@individual.net>
············@gmail.com wrote:
>>I guess the macro attempts to return a function object instead of
>>source code. Perhaps a quote is missing before the lambda.
>
> Found and fixed; but still don't understand why what I wrote is not
> valid and why both LW and OpenMCL didn't complain. Thank you for the
> hint.
Sidenote: ANSI Common Lisp is "just" a common ground for Common Lisp
implementations to start from. Implementations are allowed to provide
what they regard as useful extensions for explicitly undefined or
unspecified aspects. See 1.6 of the HyperSpec.
Pascal