Module Considerations

[Jim Blandy <jimb@red-bean.com>]

A number of people have voiced complaints about the present module
system; I've tried to enumerate the issues here.  I'd like to hear
people's comments on them.  I doubt we'll be able to make everyone
happy, but it's still worth talking about.


@node Module Considerations
@section Module Considerations

Here are some considerations we want to keep in mind while designing the
module system's interactions with the outside world:

@itemize @bullet

@item
The module system should support separate compilation, via any of
several methods --- Hobbit, code freezing, and byte compilation are
three likely possibilities.

@item
The module system should give the compiler enough information to allow
it to inline functions.  Coupled with the requirement above, this means
that the compiler should be able to whether a given variable will ever
be assigned to, without looking at all the source on the system.

@item
Users should be able to install modules for their own use without
affecting others on the system.

@item
System administrators should be able to install modules so that they are
accessible to all users.

@item
System administrators should be able to install a new version of Guile
without disturbing the other packages already installed.

@item
It should be convenient to split the core Guile distribution itself into
multiple modules, to avoid bloating Guile with unused code, and to
organize the system.

@item
Modules should be allowed to contain interpreted code (e.g., Scheme
source files), compiled code (e.g., object libraries), or a mixture of
the two.  For example, a Guile/GDBM interface might consist of some C
code to glue Guile together with the GDBM API, and some Scheme code to
provide commonly-used higher-level features.

@item
Where possible, Guile should use dynamic linking to bring object
libraries into memory only as needed, but it should also support static
linking.  Some operating systems do not support dynamic linking, and it
is sometimes useful to produce a self-contained executable.

@item
Machine-dependent files (like object libraries) and machine-independent
files (like Scheme source code) should be kept in separate trees, to
allow the machine-independent files to be shared.

@item
Guile should allow modules to be written in different languages, and
then translated to Scheme for interpretation (the @dfn{translator}
idea).  For example, it would be nice to support Emacs Lisp, or provide
a language with C-like infix syntax and Scheme's semantics.

@item
As a special case of the above, Guile should support variant syntaxes
for Scheme itself --- SCSH's case-sensitive scripts, R4RS, R5RS, DSSSL,
and so on.

@item
At install time, a module should be able to check that any other modules
it needs are already installed, and warn the user of any missing
prerequisites.

@item
It should be convenient to test modules under development without
installing them.

@end itemize