[m-dev.] module system discussion

[Peter Ross]

On Tue, Nov 27, 2001 at 02:40:25PM +1100, Tyson Dowd wrote:
> On 26-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > Simon wrote:
> > > 2. `:- transparent_module' and `:- include_transparent_module'
> > > (we can probably do better on the names)
> > >
> > > `:- transparent_module' is a new variant of the `:- auto_import'
> > > proposal, suggested by Tyson.
> > >
> > > A transparent sub-module is defined using a `:- transparent_module'
> > > declaration rather than a `:- module' declaration, or included
> > > using an `:- include_transparent_module' declaration. A transparent
> > > sub-module is always _used_ when the parent module is imported or
> > used.
> > >
> > > This is useful for qualifying the methods of typeclasses with the
> > class
> > > name without having explicitly to import the module (and lots of
> > similar
> > > ones) everywhere, and without having to import the entire hierarchy
> > with
> > > `:- use_hierarchy'.
> > >
> > > I think Fergus was still a bit wary about this one.
> > >
> > I can imagine situations where this would be useful, however
> > import_hierarchy is sufficient for my needs.
> 
> I thought it would be very useful for all those little subclasses that
> one needs to create in order to map a bunch of classes in a namespace
> into a mercury module.
> 
> Each of these little subclasses could be put inside a transparent
> subclass.  That way if you imported or used the parent module (say,
> System__Data) you would get all the transparent submodules automatically
> "used".
> 
> So we can still use submodules to get around the possible problems with
> overloading (the submodules still introduce a new namespace) but you
> don't need to write any extra import/use statements.
> 
> Of course you can get around writing import/use statement with
> import_hierarchy/use_hierarchy, but this also has the effect of
> importing non-transparent sub-modules (such as what we map .NET
> namespaces into).
> 
I support this proposal but if some people have reservations about it, I
can live without it.  I do think there are times when the designer of a
sub-module hierarchy is just using sub-modules for namespace reasons not
for any other reasons.  In that case it makes sense to allow the
designer to do the aggregation of sub-modules.  Also there are times
when a user knows they want the entire sub-module hierarchy so it also
makes sense for a mechanism for them to do the aggregration.

I am willing to implement both as long as the result will be accepted.
I suggest making a final decision at the next Mercury meeting.

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