[m-dev.] module system discussion

[Fergus Henderson]

On 12-Dec-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> On 12-Dec-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 11-Dec-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > On 11-Dec-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > On 30-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > > > > 
> > > > > I'm not proposing the `:- transparent_module' extension just
> > > > > for .NET. I am arguing that it is generally good style to qualify
> > > > > class method names with the class name, and that it is worth adding
> > > > > a small extension to the module system to make that more convenient.
> > > > > This hasn't come up before because we haven't used typeclasses much
> > > > > before, and especially not in large module hierarchies.
> > > > 
> > > > Wouldn't ordinary nested modules and `:- use_hierarchy' suffice,
> > > > both for Mercury type classes, and for interfacing with .NET?
> > > 
> > > I don't think it's OK to have to `:- use_hierarchy System'
> > > to use the classes defined at the top level.
> > 
> > If you have a deep hierarchy, then I would argue that it is bad style
> > to define classes at the top level anyway; they should be defined
> > in modules at the leaves of the hierarchy.
> 
> I'm not sure that's right. For a sub-hierarchy of a module hierarchy
> there may be some types and classes used by all elements of the
> sub-hierarchy. Those types can either be placed in the root module of
> the sub-hierarchy, or in a leaf sub-module of the root. Placing them in
> a sub-module adds an extra thing to remember (the name of the sub-module)
> and an extra module to import.

If you're planning on putting these types and/or type classes
in a transparent sub-module, then you'll still need a name
for the transparent sub-module.  So there's nothing extra
to remember.

The *only* difference between transparent and opaque sub-modules
is the extra module to import.  And if the stuff in the sub-module
is really distinct enough to warrant a named sub-module, then IMHO
it does not seem unreasonable to ask that you explicitly import it.

If you really want to avoid those two issues, then the types and/or
type classes in question can be placed directly in the top-level module,
rather than in a (transparent or opaque) sub-module.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------