On 21-Oct-1998, David Barton <[EMAIL PROTECTED]> wrote:
> Fergus Henderson writes:
> 
>    I don't think three levels is really satisfactory.
...
>          (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)
> 
> <snipping the discussion...>
> 
> OK, I am confused (I *still* suspect I am missing something basic).
> As far as I can see, the depth of the call tree (what VHDL calls the
> design hierarchy) has nothing to do with the need for an
> arbitrary-depth library directory structure.

The above hierarchy has no direct relationship with the depth
of the call tree (the call tree is significantly deeper!). 
"Design hierarchy" is an appropriate name for it, I think.

> To be specific:
> 5) The submodules of HLDS all export the names they need internally,
>    and a gather module in that directory imports and exports names
>    that are visible to HLDS.
> 
> 4) The modules of HLDS import the gather module of the submodules,
>    along with other modules at their same level; a gather module
>    imports the names for export from the entire "package" and exports
>    them.
> 
> (3) The major subcomponents import the HLDS module and other imports
>     at their own level; a gather module exports names farther up the
>     design tree.

OK, I had missed something there.  Now I understand what you mean.

This will work well, if your gather modules are small.
However, at least in the case of the Mercury compiler, the number
of entities exported from a single major subcomponent to
other major subcomponents may be very large -- large enough
that it is beneficial to impose some structure on each gather
module by grouping the features into sub-modules within the
gather module.

Now perhaps in theory the interface to each component at
whatever level should be small.  However, in practice that
is often not possible to achieve, particularly for components
which are in fact libraries of general-purpose routines.
For example, the standard library for a given language
may well be very large, and you may want the interface
to be structured, so that users of the library can say
`import std.io, std.string' to get just part of it,
rather than just `import std' to get all of it.
Similarly I want to be able to say `import hlds.data, hlds.goal'
rather than just `import hlds'.

> If the argument is that there are times when a module at level (3)
> will need a name at level (5), and therefore the nested module name
> makes sense in this case:

Not exactly.  But modules at level 4 or 5 may need names defined in
other modules at level 4 or 5 that come from a different major subcomponent
(level 3).

For example, the level-4 module `mode_errors', which is a part of
the level-3 subcomponent `mode_checker', needs access to
the routines for the level-5 ADT `proc_info' which is defined
in the level-4 module `hlds_pred' which is defined in the level-3
subcomponent `hlds'.

I suppose this is almost the same as saying that the
level-3 subcomponent `mode_checker' needs access to the
routines for the level-5 ADT `proc_info'.

> to my mind, this is a sufficient violation
> of information hiding that it deserves explicit documentation, in the
> form of another gather module at level (5) containing the
> "skip-a-level" names, which the module at level (3) imports separately
> from the module at level (4).

I don't quite understand what you're getting at here;
could you elaborate what that would mean for this example?
Did you mean to say another gather module at level (4)?

-- 
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.


Reply via email to