modules

[ramsdell%linus@mitre-bedford.ARPA]

Thanks to Will for his fine summary of the Scheme meeting.  My highest
priority item for changes to Scheme is the inclusion of macros.  I was
quite happy when Will reported:
------------
MACROS

The situation is pretty much ok.  It looks like most of the work is
going to have to be done by people at MIT, because that's where the
largest concentration of macrologists seems to lie.
------------------- 

I have directed my attention to my second highest priority: modules.
I decided to start by surveying modules in existing languages.  I
ignored COBOL, FORTRAN, Pascal, C, PL/1 (Hmm... aren't they the most
used languages?), and Prolog, as those languages have little to say on
the subject of modules.  I looked closely at ML, Modula-2, Ada, CLU
and Common Lisp.  While the solutions these languages and their
environments present to the problem of organizing and structuring
large programs suggest many possibilities for Scheme, I in no way
would like to preclude a novel approach.

I've noticed three broad goals of module systems:

1. Logical separation of information -- in which information
describing an interface is shared, but information describing an
implementation is hidden (All).  Multiple implementations of the same
interface is often also sometimes goal.

2. Physical separation of information -- in which compilation of
modules can proceed the compilation of the entire program with out
greatly affecting the quality of code produced (ML, Modula-2, Ada).
Compilations are performed with knowledge of all relevant interfaces,
so that inter-module type checking can be performed, and the compiler
can use the type information.  Usually, the subject of precompiled
libraries and recompilation control, like Unix make, are also
addressed.

3. Object-oriented programming support -- in which instances of
modules are *interpreted types*, wherein the data object and its
operations are considered as a generalized form of type (ML, CLU).

I know that some Scheme people are interested in supporting block
compilation, so physical separation of information should be a goal.
I'm sure all would like a module system to support logical separation
of information, but I think using modules to support object-oriented
programming is debatable.  Of course, my characterization of the goals
of modules in other systems is debatable, a debate I welcome.

Common Lisp's view of logical separation consists of limiting the
access of some symbols, and I suspect it can quickly be dismissed.

One difference between modules in CLU and in Modula-2, ML, and Ada, is
the latter languages have separate constructs that declare an
interface and an implementation.  This separation is strongly
supported by users, and I hope a Scheme module system allow the same
separation.  Furthermore, ML and Ada allow parameterized
implementations which are instantiated.  This also seems to be a win.

It seems that ML's module system is a better than Ada's as a base from
which a Scheme module system may evolve.  For one reason, ML shares
the goal of supporting interactive program development unlike Ada.
However, the following changes to Ada suggested by some Ada people
here at MITRE may be useful.

1. Implementations (package bodies in Ada) should be first-class so
that object-oriented programming is better supported.

2. Explicit control of what is imported should be added.  This can be
used to insure code remains valid even when interfaces change.

3. Multiple levels of hiding should be added.  In Ada (and the other
languages as well), you either have access to all an interface
exports, or you have access to nothing.  They want the use of an
interface to determine what is exported.

Then again, maybe these suggestions won't be useful.  I encourage all
to look at David MacQueen's article in the 1984 LISP and Functional
Programming Conference called "Modules for Standard ML".

John