[m-dev.] module system discussion

[Simon Taylor]

On 12-Dec-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 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:
> > > 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.

The name of the sub-module is the name of the type or class.

I took your first statement above to mean that instead of this:

	:- module module1.
		:- module class1.
			:- typeclass class1 where ...
		:- end_module class1.
		:- module class2.
			:- typeclass class2 where ...
		:- end_module class2.

		:- include_module module1__sub_module1.
		:- include_module module1__sub_module2.
	:- end_module module1.

you should write this:

	:- module module1.
		:- module classes.
			:- module class1.
				:- typeclass class1 where ...
			:- end_module class1.
			:- module class2.
				:- typeclass class2 where ...
			:- end_module class2.
		:- end_module classes.

		:- include_module module1__sub_module1.
		:- include_module module1__sub_module2.
	:- end_module module1.

So now you could import module1 and its classes (but not sub_module1
and sub_module2) using
	:- import_module module1, module1__classes.
	:- use_hierarchy module1__classes.

where with transparent sub-modules you would just write
	:- import_module module1.

> So there's nothing extra to remember.

The `classes' module name is the extra thing to remember.

Maybe I misunderstood. 

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

The whole point of this discussion is that sometimes you need a
named sub-module for things that aren't really distinct.
 
> 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.

No, they can't be placed in the top-level module because of possible
name clashes, which is why we started talking about putting them in
sub-modules in the first place. 

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