Re: Strange undefined binding bug coupled to module system

[Mikael Djurfeldt]

Marius Vollmer <address@hidden> writes:

> I'd say a good behavior for 'define' then is the following:
>
>  - When the defined name has a local binding, use that binding.
>
>  - When the defined name has an imported binding, look up the value of
>    that binding and make a new local binding initialized with that
>    value.
>
>  - When the defined name has no binding, make a new one and initialize
>    it with #<unspecified>.
>
> Then the expression is evaluated and the new (or old local) binding
> from above is set to the resulting value.
>
> Ok?

Yes, and, in addition, you need to do

  - Evaluate the body

  - Set! the binding to the resulting value

Most of this is trivial.  However, step 2 requires some coding.  Let's
break down step 2:

  2.1 When the defined name has an imported binding
  2.2 Look up the value of that binding
  2.3 Make a new local binding initialized with that value

Steps 2.1 and 2.2 could be done by calling scm_sym2var with definep =
#f, but what you would *not* want to do is to call scm_sym2var with
definep = #t in step 2.3, because that would result in two traversals
of the module tree.

What's needed seems to be to factorize scm_sym2var a little.

Or, we could switch to the environments.c implementation!  :-)

M