Re: Two questions about the guile module system

[Joris van der Hoeven]

> > I now notice that my solution from yesterday does not work with more
> > recent versions of guile.
>
> I have tested it with guile-1.6.3 and recent CVS HEAD; both work fine.
> What version are you talking about and what goes wrong?

The code does indeed re-export all symbols from an imported module,
but it does not solve my original problem.

In guile 1.3.4, I could put the following in my main initialization file:

  (use-modules (boot-stuff)) ; defines export-from
  (use-modules (std-lib-1) ... (std-lib-n))
  (export-from (std-lib-1) ... (std-lib-n))
  ...
  (use-modules (appl-mod-1) ... (appl-mod-k))
  ...

When doing this, I can use all variables exported by
the standard libraries std-lib-1, ..., std-lib-n
inside appl-mod-1, ..., appl-mod-k.

Unfortunately, this mechanism breaks in guile-1.6.3.
The point is that, during the importation of
appl-mod-1, ..., appl-mod-k, the outer context is lost.
It seems that only a very minimal context is visible
inside the application modules.

Nevertheless, before the actual (define-module (appl-mod-i))
definition is issues, the original context *is* visible.
So if one defines a 'define-my-module' macro,
then that macro can be used, although this might be unsafe.

> (Btw, there is also module-map which might be more natural to use in
> place of module-for-each.)

What does that routine do?

> > This makes it impossible to enhance the root environment
> > with even a single macro like 'define-my-module'.
>
> I find this not to be true, but it is indeed tricky to reason about
> the context in which modules are loaded.

So how can I make things such that whenever I declare a new module,
then all symbols which are visible in the initial context
are available by default?

This important, since I also noticed that even the C++ routines
which I glued to Guile are not available inside my modules!