[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