Re: set-current-module broken in current Guile CVS version (anyone?)

[Marius Vollmer]

Matthias Koeppe <address@hidden> writes:

> guile> (begin (define-module (xyzzy)) (define xyz 3456) (define-public (def) 
> xyz))
> guile> xyz
> 3456
> guile> (use-modules (xyzzy))
> guile> def
> #<procedure def ()>
> guile> (def)
> standard input:6:1: In procedure def in expression (def):
> standard input:6:1: Unbound variable: xyz
> ABORT: (unbound-variable)
> 
> The first line was supposed to put a private definition of `xyz' in
> the (xyzzy) module. It ended up in (guile-user) though.  `def' ended
> up in (xyzzy), so its body can't see the `xyz' binding.
> 
> I don't really understand the module system but this behaviour is
> simply broken.

Yep, it's broken.  It's partly because `begin' behaves wrong (its
subforms are no longer considered top-level when it comes to the
module system).

I want to fix this.  That is, I want to straighten out the sematics of
the current module system.  No big changes will be made, like the
meta-commands shown by Keisuke.

First thing is to make the repl use `eval-in-current-module', then to
change the evaluator to respect the top-levelness of subforms of
top-level `begins' (I want to do this by special casing this so that
the time-critical code for working with lexical environments does not
need to cahnge in any way) and then to take a deep look at
`define-public', etc.  For example, `export' should only have effects
on the top-level.  More advanced module hackeries should be done with
the procedural interface to modules, like `module-define',
`module-export'.