On 20-Oct-1998, David Barton <[EMAIL PROTECTED]> wrote:
> I really do think that one additional level (from the <module> <name>
> pair to a <library> <module> <name> triple) and mapping between
> libraries and directories via user variables is all we need.
I don't think three levels is really satisfactory. Let me give an
example. The Mercury implementation (0) includes source code for
several programs, the largest of which is the Mercury compiler (1).
The Mercury compiler is in turn composed of a number of libraries
plus the object files for the compiler itself (2). The compiler
is composed of a number of major sub-components (3).
For example, one of these sub-components is
called the "High Level Data Structure" or HLDS. The implementation of
this subcomponent is divided into modules (4), called hlds_goal,
hlds_pred, hlds_module, hlds_data, and hlds_out, each relating to a
particular aspect of the HLDS, with a separate source file for each
module. Each of these modules defines several different abstract data
types and/or groups of related operations, which should really
themselves each be sub-modules (5), since (in both Mercury and Haskell)
the module is the unit of encapsulation.
(0) distribution:
Mercury, ghc, hugs, ...
(1) programs (within the Mercury distribution)
mmc, mprof, diff, ...
(2) top-level components/libraries (of mmc)
compiler, standard library, runtime, GC, debugger, ...
(3) major sub-components (of compiler):
parse tree, HLDS, LLDS, type checker, mode checker,
determinism analysis, code generator, optimizer,
value numbering, ...
(4) modules (for HLDS):
hlds_data, hlds_goal, hlds_pred, hlds_module, hlds_out
(first four are high-level representations of data, goals,
predicates, and modules in the language being compiled;
the last is routines to pretty-print these)
(5) sub-modules (of hlds_data)
constructors, types, insts, modes, type classes
(these are ADTs or functional groups within a module)
Note that levels 0 and 1 need not be part of any module system:
names defined in one program won't clash with symbols of the same
name in a different program! So this is really only four levels.
But that's still one more than three.
At each of levels 0-4, the branching factor is typically at least 5
(i.e. there are typically at least five other units at the same level);
at level four the branching factor drops off a bit, but it still
varies from about 1-5, with 3 being common.
The Mercury compiler itself is less than 150,000 lines of Mercury code
(including whitespace and comments). I could easily give lots more
examples from that code where four levels would be useful. There may
even be some examples where five levels would be useful. I think it is
very likely that by the time you get to say a million lines of source
code that another level would be helpful.
Initially Mercury had only a flat module system, like Haskell. But we
found ourselves running into the limitations of that system on a
regular basis. We had some quite long discussions on the developers
mailing list about what the best solution was. Initially I advocated
adding "packages" as a separate concept at the next level above modules
(the distinction being that a package can only define modules, not
types/functions/etc.), but eventually we decided to just go for
allowing arbitrary nesting of modules, with both physical inclusion and
logical inclusion. The discussion on the mailing list is archived at
<http://www.cs.mu.oz.au/mercury/mailing-lists/mercury-developers/list.html>.
The Mercury module system is described at
<http://www.cs.mu.oz.au/mercury/information/doc/reference_manual_9.html#SEC33>.
Implementing nested modules initially seemed very simple, but turned
out to be a bit trickier than I had originally thought -- the current
development version still has several unfixed bugs relating to nested
modules.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
