Modules

[Matthew Tuck]

Modules
-------

This is a message about how I see "modules" fitting into the system. 
This should be familiar to anyone who knows C, since they correspond to
files.

My modules are not information hiding mechanisms, and they have no
namespace.  The correspond to files, and they are orthogonal to these
issues.  This is unlike C(++)s files, where there is a "static" keyword
that prevents export from the file.  My modules have nothing like this.

What are modules for then?  There are several uses of modules.

(a) They are an element of reusability between projects (sets of
modules).
(b) They are a grain of access control in a multi-programmer system. 
Basically, there would potentially be different access control over each
module.
(c) They are an element of exchangeability.  This means having multiple
modules with the same interface to the rest of the program.  This
differs from multiple implementations in that if a module is not
included, it need not compile.  This is essential for handling different
platforms, if we are to remove the need for conditional inclusion (#ifs
and #ifdefs).

Modules are a collection of top-level elements, which will usually be
classes/singular objects/etc.  Hence modules are thrown together into
one program, none having a priveleged status over another.  You can
imagine this as concatenating text files, if the merging were text
files.  Since we are editing ASTs, there is no need for rules
prohibiting forward references.

My view of the way the editor should handle this, is to normally not
show the modules at the top of the hierachy, although it could allow
this.  Hence the modules would normally might be transparent, except for
perhaps something to indicate you don't have write access to that code. 
Some facility must exist to move top-level elements between modules.

It should be stated that the module concept is independent of the rest
of the language.  Hence we could comfortably create an initial
implementation with no module system and handle everything by copying
and pasting.  But there is one situation where the language could help
...

Separate Compilation
--------------------

I already have allowed multiple elements in a module.  For the module
system to be further independent of the nesting system (ie information
hiding) we need to allow an element to span multiple modules.  We might
not want the same access control over an entire element, or we might
want to allow swapping a smaller part with a similar part.  This smaller
part would essentially be a nested class or method.

Hence the language could support some sort of separate compilation
system similar to that of Ada, where they are called "subunits". 
Essentially this puts a stub where the nested element would go and
allows it to be provided separately as a physically top-level element,
although conceptually still within the other element and hence getting
private member access rights.  From there on it can be moved into
another module and hence swapped and access controlled separately.

If nesting classes became too deep we might want to do this to avoid
having a deep program tree, while retaining the information hiding
advantages.

This implies there is some use of separate compilation outside of
modules, although its main benefit lies there.

The editor would provide facilities such as "separate", "separate and
move to module ..." and "recombine" to handle splitting and recombining.

Some issues that might arise in the compilation process would be as
follows:

(1) Need to typecheck an element in a different module from it's
surrounding element.
(2) Could not be optimised well until the modules are linked together.
(3) Being able to see a top-level element no longer implies you can
access it.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
             mailto:matty@box.net.au (ICQ #8125618)
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/