[iterate-devel] Fwd: iterate form evaluates but does not load into sbcl fasl
szergling
senatorzergling at gmail.com
Mon Feb 8 22:36:21 UTC 2010
On 2/9/10, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
> Hello,
>
> (A copy of this email was recently sent to the gsll and sbcl mailing lists).
>
> The package gsd <http://repo.or.cz/w/gsd.git>, part of
> gsll<http://common-lisp.net/project/gsll/>uses iterate to loop over
> elements of vectors and matrices. I have attached
> the part of the package that extends iterate to this email.
>
> I am having the following issue on sbcl1.034 on RHEL5 64-bit linux, via
> slime.
>
> The following form evaluates OK at the REPL.
> (iter:iter
> (iter:for c :matrix-row grid::*array-3-4-double-float*
> )
> (print c))
>
> But, if I embed it into a function:
> (defun foo ()
> (iter:iter
> (iter:for c :matrix-row grid::*array-3-4-double-float*)
> (print c)))
>
> it will evaluate OK in slime (C-x C-e), but will not compile (C-c C-c). The
> returned error is:
>>>>
>
> post-processing/xpdp-post-processing.lisp:75:3:
> error:
> Objects of type FUNCTION can't be dumped into fasl files.
> --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE
> --> SB-KERNEL:%COERCE-CALLABLE-TO-FUN
> ==>
> #<FUNCTION (LAMBDA #) {1002DD7AD9}>
>
> note:
> The first argument never returns a value.
> --> LET* BLOCK TAGBODY PROGN SETQ THE FUNCALL SB-C::%FUNCALL THE
> ==>
> (SB-KERNEL:%COERCE-CALLABLE-TO-FUN #<FUNCTION # {1002DD7AD9}>)
>
> ... more stuff
>>>>
Hi Mirko,
I didn't actually look into this, but it sounds like a problem with
externalising
literal functions. Unlike, SBCL, clisp (the implementation) doesn't seem to
have this problem (or at least I could reproduce it). See this snippet below:
(defun my-car (x)
(macrolet ((m ()
`(funcall ,#'car x)))
(m)))
Try and COMPILE-FILE the above as a file in SBCL, and compare clisp.
I believe this is related to the reason why some Lispers often write
(funcall 'some-function ...) instead of (funcall #'some-function ...),
since symbols are externalisable. For more details, check out
the hyperspec entry for compile-file, and look for the link
on "Literal Objects in Compiled Files".
I hope my hunch about this is correct, caveat emptor!
> So, it seems that sbcl can digest it, but for some reason cannot write it to
> a fasl.
>
> The macroexpansion of the code above is:
> (LET* ((#:SEQUENCE120 NIL) (#:LIMIT121 NIL) (C NIL) (#:INDEX119 NIL))
> (BLOCK NIL
> (TAGBODY
> (PROGN
> (SETQ #:SEQUENCE120 GRID::*ARRAY-3-4-DOUBLE-FLOAT*)
> (SETQ #:LIMIT121 (FUNCALL # #:SEQUENCE120))
> (SETQ #:INDEX119 -1))
> LOOP-TOP-NIL
> (PROGN
> (SETQ #:INDEX119 (+ #:INDEX119 1))
> (IF (>= #:INDEX119 #:LIMIT121)
> (GO LOOP-END-NIL))
> (SETQ C (FUNCALL # #:SEQUENCE120 #:INDEX119))
> (PRINT C))
> (PROGN)
> (GO LOOP-TOP-NIL)
> LOOP-END-NIL
> (PROGN))
> NIL))
That # #:SEQUENCE120 looks funny. Is it meant to be #'#:SEQUENCE120?
Maybe it's not what I thought it was...
> Is this issue due to a malformed extension of iterate, or some misalignment
> between iterate and sbcl?
>
> Thank you,
>
> Mirko
>
Anyway, hope this might help.
Yong.
More information about the iterate-devel
mailing list