Modules, guile factorization, initial environment (Re: O-O in guile)

[Mikael Djurfeldt <mdj@nada.kth.se>]

Telford Tendys <telford@eng.uts.edu.au> writes:

> Doesn't this sound a bit backwards? Surely the default situation with
> no modules loaded is to get the most pure and primitive behaviour.
> I expect that new users are easily enough confused without telling them
> that you have to load extra modules in order to get less functionality.

When we get the module system and have factorized Guile, it will of
course be a simple thing to choose which modules should be pre-loaded.
I say this only to indicate that there is no hurry in the debate over
this question---the design of the new `set!' won't be affected.

Also, it is not yet decided exactly what code should be pre-loaded and
what should not.  What I say below is not the developers' policy, but
my own view only.

It seems clear that there should exist a pure RnRS module.

Could we, in fact, let libguile be only an RnRS module?

No.  In order to implement the RnRS functionality with an internal
architecture which allows efficient extension to the basic features
that we want Guile to support we need code which can be "published"
and is useful on the Scheme level in its own right.  Example: The
predicate `thunk?' is used internally for argument checking, but can
be useful in user programs, so it is published as a Scheme procedure
as well.  Another example is the machinery around error handling, like
`catch' and `throw'.

Also, there is some basic extra functionality which is useful enough
to grant a place in the "standard" Guile language and therefore should
be distributed with libguile.  Examples: `defined?', `getenv', records.

So, libguile should clearly consist not of a single module, but of a
set of modules.

But then one could still have the RnRS module as an initial
environment, and let the user choose what other modules to add, no?

One goal of Guile is to be a practical Scheme implementation.  It is
aimed at using Scheme in applications.  The core Scheme functionality
is too small to be useful directly in applications programming---it
needs to be complemented by library functions.  Now, most libraries
should of course be explicitly loaded, but I would get mad if I had to
load the list module every time I wanted to remove an element in a
list with the `delq' operation.  I think `delq' is an example of an
operation which should belong to a core Guile language.

In practise, we could decide what operations apart from the RnRS ones
which should belong to the practically useful core Guile language, and
put them (or import them) into a `guile-extensions' module and import
and reexport the bindings in the `RnRS' and `guile-extensions' modules
from the `guile' interface.

There is a third thing to consider: The needs of a program are
different than the needs of the user regarding the environment.  The
user needs to easily set customization options or use session support
utilities like `apropos'.  The program doesn't need this.

Therefore, my view is that there should be bindings imported from a
session support module as well, so the default bindings in an
interactive session should come at least from three different modules:
RnRS, guile-extensions and session-support.

Given that we support generalized locations a la new `set!', I think
they should belong to the core language.

Regarding OO extensions: There is only some minimal OO support
required in libguile, and none of this needs to be visible at the
Scheme level.  This minimal support (like a few lines extra in eval.c)
is needed in order to support a fast OO system.

/mdj