Fergus Henderson writes:
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.
Good enough; new (to Haskell) terminology defined.
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'.
Is there a reason why these cannot be separate gather modules (just as
in C they are separate include files)? I suppose in an extreme case
you might want to do a completely separate library with nothing but
smaller chunks of gather modules; if so, the present structure allows
it.
> 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'.
OK; I think the reexport facility covers this.
> 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)?
If level (3) needs visiblity over a level (5) name that level (4)
really does not use at all, this gets a bit problematic; however, it
really does happen a lot in real life. This can be handled either by
having (4) import it and pass it through, or by a special gather
module at level (5) that level (3) imports separately. At least,
that's what I *think* I meant......
Are you really up this late? My merciful heavens!
Dave Barton <*>
[EMAIL PROTECTED] )0(
http://www.averstar.com/~dlb
