Re: Strange undefined binding bug coupled to module system

[Mikael Djurfeldt]

Mikael Djurfeldt <address@hidden> writes:

> Loading of the following code:
>
> foo.scm:
> ----------------------------------------------------------------------
> (define-module (foo))
>
> (define (encapsulate proc)
>   (lambda (_) (proc _)))
>
> (display round)
> (newline)
> (define round (encapsulate round))
> ----------------------------------------------------------------------
>
> Gives (since some change during last spring):
>
> guile> (load "foo.scm")
> #<primitive-procedure round>
>
> Backtrace:
> In unknown file:
>    ?: 0* [primitive-load "foo.scm"]
> In foo.scm:
>    8: 1* (define round (encapsulate round))
>    8: 2* [encapsulate ...
>
> foo.scm:8:15: While evaluating arguments to encapsulate in expression 
> (encapsulate round):
> foo.scm:8:15: Unbound variable: round
> ABORT: (unbound-variable)

OK, I've found the change which causes it:

2004-04-22  Dirk Herrmann  <address@hidden>

        (scm_m_define): Change order to first create binding and
        evaluating the expression afterwards.

While this change works in the R5RS situation without a module system,
the presence of a module system, with the difference between imported
and local bindings, introduces complications.

It seems like, in the case where no local binding exists before, that
local binding should be created *initialized* to the value of the
corresponding imported binding, if that exists.  That is not done now,
which causes the above described non-intuitive behavior.

Since it's not immediately obvious to me how to fix this in a good
way, I'll leave that to you guys.  But please keep in mind that
variable lookup is a substantial part of loading time in Guile.  We
wouldn't want to make *two* eval closure traversals by invoking
scm_sym2var twice (with different value of definep) or something like
that.

M