[Gsll-devel] bug in grid/iterate?

[Liam Healy]

Mirko,

This appears to be a bug in iterate, or maybe an iterate misuse in grid.
I am told that the "#" means print level exceeded.  The real error is that
the iterate macroexpansion is inserting a function directly in the output.
SBCL will accept that "live" but won't write a FASL that way.  It isn't
interpreted vs. compiled, because SBCL always compiles unless you
go out of your way to get it to interpret.  The error is:
"Objects of type FUNCTION can't be dumped into fasl files."

In CCL, I get the expansion

(macroexpand '(iter:iter (iter:for e :matrix-row *array-3-4-double-float*)
         (princ e) (princ " ")))
(LET* ((#:SEQUENCE8 NIL) (#:LIMIT9 NIL) (E NIL) (#:INDEX7 NIL))
  (BLOCK NIL
    (TAGBODY (SETQ #:SEQUENCE8 *ARRAY-3-4-DOUBLE-FLOAT*)
             (SETQ #:LIMIT9
                   (FUNCALL #<Compiled-function (:INTERNAL

ITERATE::CLAUSE-FOR-MATRIX-ROW-1) (Non-Global)  #x30004154224F>
                            #:SEQUENCE8))
             (SETQ #:INDEX7 -1)
     LOOP-TOP-NIL (SETQ #:INDEX7 (+ #:INDEX7 1))
             (IF (>= #:INDEX7 #:LIMIT9) (GO LOOP-END-NIL))
             (SETQ E
                   (FUNCALL #<Compiled-function (:INTERNAL

ITERATE::CLAUSE-FOR-MATRIX-ROW-1) (Non-Global)  #x30004154283F>
                            #:SEQUENCE8
                            #:INDEX7))
             (PRINC E)
             (PRINC " ")
             (GO LOOP-TOP-NIL)
     LOOP-END-NIL)
    NIL))
This pretty clearly shows that it is producing a function, not an
S-expression as you see,
but this is all in the iterate code.

Did you cross-post to the iterate list?  I don't belong to that list so maybe
you can pass the information on to them and see if the have a suggestion.

Liam


On Fri, Jan 29, 2010 at 3:38 PM, Mirko Vukovic <mirko.vukovic at gmail.com> wrote:
> Apologies for cross posting, but I am not sure where this problem belongs
> (iterage or gsll).  I use slime (updated a few days ago) on sbcl 1.031 on
> linux.   I have problems compiling the following file:
>
>>>>
> (in-package :grid)
>
> (defun foo ()
>   (iter:iter (iter:for e :Matrix-row grid::*array-3-4-double-float*)
>          (princ e) (princ " ")))
> <<<
> (the code is from the iterate.lisp file of the distribution)
>
> Now in slime, I have problems.  Evaluation works:
>
> I can do C-x C-e to compile `foo'
> I can also do C-M-x
>
> But compilation does not.  Both C-c C-c and C-c C-k will flag a compiler
> error:
>   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 # {10030285A9}>)
>
> Same story in raw sbcl.
>
> I looked at the iterate.lisp source code and see nothing obvious.  But, I am
> not sure what to make of the following:  If I macro-expand the above code
> (iter:iter ... (iter:for ... :matrix-row ...(...)))  I get the following
> expansion.  The puzzling thing is thta the first argument to `funcall' is a
> single hash character `#':
>
> (let* ((#:sequence208 nil) (#:limit209 nil) (e nil) (#:index207 nil))
>   (block nil
>     (tagbody
>        (progn
>      (setq #:sequence208 *array-3-4-double-float*)
>      (setq #:limit209 (funcall # #:sequence208))  ;;  <-----
>      (setq #:index207 -1))
>      loop-top-nil
>        (progn
>      (setq #:index207 (+ #:index207 1))
>      (if (>= #:index207 #:limit209)
>          (go loop-end-nil))
>      (setq e (funcall # #:sequence208 #:index207)) ;; <-----
>      (princ e)
>      (princ " "))
>        (progn)
>        (go loop-top-nil)
>      loop-end-nil
>        (progn))
>     nil))
>
> Instead of the single hash mark, I would have expected the :access-fn and
> :size-fn `lambda's from the (defclause-sequence matrix-row matrix-row-index
> ...) in iterate.lisp.
>
> So, lots of puzzles.  Not sure where this bug belongs: iterate or grid?
>
> Thanks,
>
> Mirko
>