[m-dev.] module system discussion

[Peter Ross]

Fergus wrote:
> On 13-Dec-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> >
> > 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!).
>
> It's always a trade-off.  For a feature to be worth adding to the
> language, it's not enough that it would sometimes be appropriate to use
> that feature if it were present.  The feature has to provide a substantial
> benefit (relative to the increase in language complexity that it causes).
>
> For functions, it's clear to me that they provide very substantial
benefit,
> at little cost in increased complexity.
>
> For transparent modules, the increase in complexity seems to me to be
> similar to the increase in complexity for adding functions, but the
> benefit seems much much less.
>
To me the complexity doesn't seem that much.

I will reiterate my view that sometimes sub-modules are used purely for the
namespace reasons, not because the sub-module contains new but related
functionality. In this case I believe we should allow an easy mechanism to
group these logically related sub-modules into one sub-module.  The
transparent_module mechanism gives us a mechanism to do this.

I think the transparent_module name is misleading, and to use the following
name would be better:

:- namespace ns.
:- end_namespace ns.

we should also restrict the use of the following declaration to only appear
inside one module, ie you cannot have separate sub-modules.  This is a good
idea because we are saying that the items are logically related, so they
should have to be in the same source file.  You are not allowed to have
sub-module with the same name as a name-space.

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