[m-dev.] module system discussion

Peter Ross peter.ross at miscrit.be
Wed Dec 12 22:33:48 AEDT 2001

On Wed, Dec 12, 2001 at 05:31:12AM +1100, Simon Taylor wrote:
> On 12-Dec-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > 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 agree, why should we force the programmer to not use the natural names.

To me it is bad software engineering to have to contrive the names to
avoid clashes.

For example, when using the field syntax I quite often have the problem
with wanting to use the same field name in different types.  So you end
up with fields called: name, modulename, modname, mod_name, module_name,
mname, etc., etc..  The transparent_module proposal allows us to place
the type in its own sub-module and all the name conflicts go away.

> 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.
I agree, and I think the example of named fields highlights why we would
want to do this.

> > 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.
Again I agree!
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

More information about the developers mailing list