[m-rev.] for review: make compiler use sub-modules

[Fergus Henderson]

On 06-Mar-2002, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> common should probably be a sub-module of simplify.

Hmm... I just remembered why I avoided this kind of thing.

In general it is a bad idea to have complicated modules containing
both code and sub-modules.  Making `common' a sub-module of `simplify'
means that `common' would have access to the private parts of `simplify'.
But `common' doesn't need that access.  Therefore it is better to leave
it as a separate module, rather than making it a sub-module of `simplify'.

So I think I will undo that change.  Likewise, for similar reasons
I will not make `constraint' a sub-module of `deforest'.

> I don't think smart recompilation belongs under hlds. Leaving it
> as a separate component with recompilation.check, recompilation.usage
> and recompilation.version as sub-modules of recompilation is probably
> the best approach.

This one I will keep.  In this case, the top-level module is fairly
simple, has no private stuff (every single predicate and type in it
is exported), and all of the sub-modules already import it.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------