[m-dev.] module system discussion

[Tyson Dowd]

On 27-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> 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.

As far as I know, the people who were interested in the issue (Simon,
Fergus and myself) were in agreement that this was a good idea, and the
Simon would write up the specification (which he has).  Nobody else was
interested enough to stay for the whole discussion.

So I don't see the need for further debate now (except perhaps wrangling
over syntax for transparent_module), we should just implement it and try
it out.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------