Re: set-current-module broken in current Guile CVS version

[Dirk Herrmann]

On 27 Dec 2000, Matthias Koeppe wrote (to bug-guile):

> Some of the Guile changes since 2000-12-13 broke
> `set-current-module'.
> 
> guile> (define-module (guile-ilisp))
> #<directory (guile-ilisp) 8082e70>
> guile> (define-module (guile-user))
> #<directory (guile-user) 8082a70>
> guile> (set-current-module (resolve-module '(guile-ilisp)))
> guile> (current-module)
> #<directory (guile-user) 8082a70> ; should be guile-ilisp

The problem is even worse than that:  already the first line of your
example fails:

# guile
guile> (current-module)
#<directory (guile-user) 5d5c0>
guile> (define-module (guile-ilisp))
#<directory (guile-ilisp) 5d8c0>
guile> (current-module)
#<directory (guile-user) 5d5c0>

The reason is the following:  scm_eval takes an expression and an
environment parameter.  This means, that during the execution of the
expression the given environment shall be active, but after scm_eval
returns, the environment of the caller has to be restored.  Up to
December, 15th guile's eval did not update (current-module) when switching
to the given environment.  Instead, within the evaluated code a call to
(current-module) would still report the environment of the caller of
scm_eval.  Since (current-module) was not changed when entering the
dynamic scope, it was not restored either.  Thus, changes to
(current-module) which occured during the execution of the evalutated code
simply 'escaped' the dynamic scope of the evaluated expression.  Now, this
is 'fixed', which means, that scm_eval performs as described above, namely
setting up the environment, executing the given expression in that
environment, and finally restoring the original environment.

The erroneous behaviour that you detect is due to the fact, that the repl
expects a different behaviour of scm_eval:  In this case, any switches to
different environments should be kept after scm_eval returns.

There are two possibilities:  

* We provide two different scm_eval functions, one that is 'safe' in the
  sense that environment switches do not influence calling code and
  another one, that allows switches to a different module remain effective
  after the function returns.  The repl would then use the second one.

* The repl is modified to somehow get the necessary information from the
  code that is evaluated.

Somehow I prefer the second solution, although I have no clear idea yet,
how that should be accomplished best.

Best regards,
Dirk Herrmann