[m-dev.] module system discussion

Ralph Becket rafe at cs.mu.OZ.AU
Thu Dec 13 17:22:24 AEDT 2001

Tyson Dowd, Thursday, 13 December 2001:
> On 12-Dec-2001, Ralph Becket <rafe at cs.mu.OZ.AU> wrote:
> > Tyson Dowd, Wednesday, 12 December 2001:
> > > 
> > > Well by this logic we can certainly remove all those (non-minimalist)
> > > functions which you and Fergus see quite keen on adding to the language
> > > and library all over the place...
> > 
> > Excquise you?
> s/see/seem/ in my text.
> I was being a bit obtuse so perhaps I will state my opinion plainly.
> What I mean is that I object to people becoming overnight "language
> minimalists".  It is easy to dismiss requests for new features on
> the grounds of minimalism.  Anything that doesn't strictly add
> expressive power is rejected out of hand.

Ah, I should have made myself clearer.  I was only agreeing with Fergus'
position that the case for transparent modules is not yet made.

I do not, however, hold a strictly minimalist approach to language
design (at least insofar as surface syntax goes).  I prefer a more
RISC-like approach where effort is expended on the common case (not
exclusively the cheap case, as RISC is often misunderstood) rather than
cases of imagined utility.

> To get to the point -- the feature is not absolutely necessary, but when
> has that ever stopped us from adding something to the language or
> advocating its use when appropriate?  I feel that you need to convince
> me that it is not appropriate to use often enough to add to the
> language (or that Mercury really is a minimal language after all!).

Right, I think we're in a state of violent agreement.

As I understand it, transparent submodules are used (a) to get around name
clashes and (b) where the *designer* of a module *expects* that the common
case will be for a user to import the submodules whenever he imports the
parent module.

`import_hierarchy' is used when the *user* wants all the submodules
imported as well.

A module hierarchy implemented using transparent submodules removes
choice from the user, offering only convenience being that the user can
use plain `import' rather than `import_hierarchy' on the parent module.

It is this loss of choice (and the opportunity for abuse) that puts me
off transparent submodules.

- Ralph
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au

More information about the developers mailing list