[m-dev.] Module qualification of typeclass methods

[Peter Ross]

On Wed, Nov 07, 2001 at 11:05:52AM +1100, Tyson Dowd wrote:
> On 06-Nov-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> > On 06-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > > Zoltan wrote:
> > > > On 31-Oct-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > > I have an alternative proposal, which was part of my original proposal
> > > > > for nested modules.  This proposal is to have a new construct
> > > > >
> > > > > :- export_module <module name>.
> > > > >
> > > > > which includes the *contents* of the specified module in the current
> > > module.
> > > > > (Maybe `export_module' isn't the best name for it.
> > > > > Other possible names include `export_module_contents',
> > > > > `module_contents', `copy', and `include'.)
> > > >
> > > > While I like the idea of this functionality, I would vote very strongly
> > > against
> > > > the name "export_module". The name "include" would be much better.
> > > >
> > > > We also need to agree on exactly what this operator would do. May I
> > > propose
> > > > tomorrow's meeting as the time and place to hash it out? Pete, you would
> > > need
> > > > to provide your input before then, of course.
> > > >
> > > What was the result of this discussion?
> > 
> > We spent a lot of time discussing record syntax, and left the module
> > system discussion for the next meeting.
> 
> I also found it difficult to explain what the requirements are of the
> extensions that are being proposed.
> 
> Can you gather together a few of the example interfaces that you are
> generating and finding difficult to use? 
> 
> And can you then list the problems that are happening with them?
> 
> We can then discuss them with a bit more background, and so better
> decide which extensions out of all the possible ones that we should use.
> 
> (Also, we are moving the Mercury meetings to Mondays, so this will be
> discussed on Monday).
> 

Here is an example of one way to map the System.Object class to Mercury
(the current way we do it).

:- module 'System'.

:- interface.

:- type 'Object'.
:- pragma foreign_type('Object', il("[mscorlib]System.Object")).

:- implementation.

    :- module 'System__Object'
    :- interface.
        :- typeclass 'Object'(T) where [
                % Instance method
            impure func 'GetHashCode'(T) = int
        ].
        :- instance 'Object'('System__Object').
            
            % Static method.
        :- impure func 'Equals'('System__Object', 'System__Object') = bool

    :- implementation.

        % ...

    :- end_module.

:- end_module.

The only real problem with this approach is that to use the
System.Object class in Mercury you need to import both the System and
System__Object modules.  I would like a mechanism which would allow one
to import just the System module and get all the required sub-modules at
the same time.

On a related note, the more I have played with allowing typeclasses to
introduce a new namespace the less I like it.  The problems as I see it
are that you need to decide what to do when you have a submodule with
the same name as the typeclass.  You may have a problem with duplicate
definitions.  Note that these definitions can be caught at compile time
in the sub-module because the parent modules declarations are visible.
The only real advantage to typeclasses introducing a new namespace is
that you don't need to introduce a new submodule to get a new namespace.

The other problem is that the change is not backwards compatible.
Fergus suggested allowing one to use the name 'System__GetHashCode'
instead of 'System__Object__GetHashCode' providing it is not ambigious.
This could be quite difficult to implement because you have to insert
module qualifiers when trying to find a match for any name.  I think
that this is not so trivial to do.

Finally the other problem I have encountered is that .NET distinguishes
between deployment units and namespaces while Mercury doesn't.  What are
peoples feelings on allowing a declaration like

:- namespace 'System__Xml'.

which allows one to also refer to entities within the current module
with the module qualification replaced with that specified by the
namespace declaration.  This is similar to Fergus' export_module
declaration but doesn't require a seperate module to achieve the
renaming behaviour.

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