[m-dev.] Module qualification of typeclass methods

Peter Ross peter.ross at miscrit.be
Thu Nov 1 22:12:55 AEDT 2001


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.
> > (Maybe `export_module' isn't the best name for it.
> > Other possible names include `export_module_contents',
> > `module_contents', `copy', and `include'.)
>
> 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.
>
> We also need to agree on exactly what this operator would do. May I
propose
> tomorrow's meeting as the time and place to hash it out? Pete, you would
need
> to provide your input before then, of course.
>
Namewise I am easy.

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 like Simons suggestion of a mechanism which says that this submodule is
also imported when the parent is imported.

Pete

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