Re: [Chicken-users] Modules again

[felix]

Grzegorz Chrupała wrote:

> Hi all,
> I have come across a mystifying error message while using modules. The 
> following code illustrates it:
>
> (module foo
>   (make-lv let-lv)
>
>   (define (make-lv id) (vector 'lv id))
>   
>   (define-syntax let-lv
>     (syntax-rules ()
>       ((_ (id ...) body ...)
>        (let ((id (make-lv 'id)) ...) body ...))))
> ;; The line below causes the error  
>   (define _ (let-lv (_) _))
>   )
>
> This gives "Error: call of non-procedure: #;> "
> SISC gives the same message so it looks like I'm using the psyntax 
> modules in a wrong way, however, I have no idea what that could 
> possibly be.
> If I comment out the last definition, the code works as expected. If I 
> include _ as an (second or third, but not first) element in the export 
> list it works too. Any ideas?

Hm.... Judging from the following excerpts from the "Chez Scheme User's Guide":

"Internal definitions and definitions within a module body are processed from left to right so that 
a module's definition and import may appear within the same sequence of definitions. Expressions 
appearing within a body and the right-hand sides of variable definitions, however, are translated 
only after the entire set of definitions has been processed, allowing full mutual recursion among 
variable and syntactic definitions."

"Although definitions within a lambda or module body are processed from left to right by the 
expander, the order of evaluation of variable definitions is unspecified. Initialization expressions 
appearing within a module body are evaluated in sequence after the evaluation of the variable 
definitions."

I'm not exactly clear why this is so, but it seems that the evaluation order of 
the
initializer expression is not as it should be. Expanding your example (witb ",x 
...")
in csi shows that make-lv get's initialized after the definition of _.
This reminds of the limitations one has with internal "letrec" definitions, 
where
the initializer may not refer directly to one of the other, parallel 
definitions.
So I assume that the evaluation order of definition-initializers that are 
exported
and those that are not exported should not be relied upon.

I'd consider this a bug, but I have to check this with Scott Miller...


cheers,
felix