[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:
> However, I'm still not convinced.  For this example,
> I'd be happy to write it just like this:
> 
>  	:- module module1.
>  		:- module classes.
>  			:- typeclass class1 where ...
>  			:- typeclass class2 where ...
>  		:- end_module classes.
>  
>  		:- include_module module1__sub_module1.
>  		:- include_module module1__sub_module2.
>  	:- end_module module1.

I don't see the advantage of doing it that way. The `classes' module
doesn't add any encapsulation, it's just another thing for the programmer
to remember.

> > > 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. 
> 
> But that only applies when you're generating these things automatically
> as part of a foreign language interface.  If you're writing the module
> by hand, you can just name the methods of the different type classes
> so that they don't clash.

Contriving names to avoid clashes also makes it more difficult for
programmers to memorise the interface. I think it's better to use
the natural names for the methods and let the typechecker deal with
any clashes.

I also think it's good style for the methods to be qualified with the
class name, and for constructors to be qualified with the type name.
Putting types and classes in their own sub-modules is an easy way to
achieve that.

> Even in the case of automatically-generated interface modules,
> name clashes can be avoided using prefixes.

That breaks the correspondence between the names in the foreign
language library's documentation and the Mercury names.

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