[m-dev.] Module qualification of typeclass methods

Simon Taylor stayl at cs.mu.OZ.AU
Fri Nov 2 00:37:29 AEDT 2001

On 01-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> Zoltan wrote:
> > On 31-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > I have an alternative proposal, which was part of my original proposal
> > > for nested modules.  This proposal is to have a new construct
> > >
> > > :- export_module <module name>.
> > >
> > > which includes the *contents* of the specified module in the current
> module.

> > While I like the idea of this functionality, I would vote very strongly
> against
> > the name "export_module". The name "include" would be much better.

Unfortunately, the best name for this feature (`include_module')
is already taken.

> > We also need to agree on exactly what this operator would do.
> However regarding the semantics.  I would like an operator which would allow
> one to include one module and get some set of its sub-modules automatically.
> I don't believe Ferguss suggestion allows that as it renames entities, so
> you lose the submodule information.  However I do think it is a good idea
> for other uses.

I'm a bit concerned that the renaming introduced by the
`include' operator will make it more difficult to answer
the question "Where is this item defined?" when reading the
source for a large program, even when the item in question
is fully module qualified. It may also cause problems for
tools like mtags.
> I like Simons suggestion of a mechanism which says that this submodule is
> also imported when the parent is imported.

I still think that proposal is worth implementing.

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