Re: initial modules.texi

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Neil Jerram <neil@ossau.uklinux.net> writes:

> - we don't really want the complete module system in core Guile,

I'd say the module system needs to be in the core.  This is part of
Guile's infrastructure.  It doesn't seem useful to have a module
system which is itself loaded, since it is the module system which is
supposed to manage loading.

>   because of (a) size

If we risk introducing features that needs too much code to support
them, I'd prefer to exclude them entirely instead of breaking up the
module system into permanent and load-on-demand pieces.

>   and (b) it goes against the principle of being
>   able to build a number of possible module systems on top of
>   Jim's/Jost's environments

I don't think so.  It's the same way here as it is regarding GOOPS and
other object system: Having a "standard" module system in the very
bones of Guile doesn't prevent using a different module system.  If we
don't have a "standard" module system, we get into many silly problems
in the core.  We can make the architecture of Guile cleaner by having
a fundamental module system, just as we can make it cleaner by having
a fundamental object system.

I *do* agree that we should try to have inner API's which enable
implementation of other systems, though, in the spirit of Jim's and
Josts' environments.

> - we do however need something in core Guile to allow C code to do
>   whatever it needs in respect of module/environment hacking.
> 
> So we need a minimal module system in the core which can be overriden
> later on the Scheme level.  Or maybe not overriden - the C and Scheme
> level interfaces don't actually need to overlap at all.  Or perhaps
> the C level environments interface already provides enough function
> for C code?

I'm sure this would get us into serious trouble.  I'm also sure that
similar C and Scheme access to the facilities of the same module
system will serve users better.


I'd like to add that we should try not to be too generic.  It will be
difficult enough to implement a real module system with useful
features such as some of those mentioned in our wishlist so far.  I
believe we can design it in a modular fashion, thereby allowing for
implementation of other systems (I doubt that this will happen in
practise, though), but if we have to design two systems, or some kind
of generic API which can "relay" requests from the C level to
different module systems, then I think we are too ambitious.

Remember Linus' Torvalds words (if I remember them correctly): "It's
not just stupid to be too generic.  It's EVIL."  :)