[m-dev.] Module qualification of typeclass methods

[Peter Ross]

On Fri, Nov 16, 2001 at 01:55:44AM +1100, Fergus Henderson wrote:
> On 07-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > On Wed, Nov 07, 2001 at 11:05:52AM +1100, Tyson Dowd wrote:
> > > 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?
> > 
> > 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.
> 
> Hmm... IMHO this is not a compelling example.
> Why not just import both the System and System__Object modules?
> That doesn't seem like such a terrible burden here.
> 
> Do you have any more compelling examples?
> 
The problem is the number of imports that you have to do.  If I want to
use some subset of the System namespace.  I must import a module for
every class that I wish to call a method on.

For example to read a row from a database table, I need the following
imports.

:- import_module 'System__Data', 'System__Data__SqlConnection',
        'System__Data__SqlCommand', 'System__Data__SqlDataReader'.

while most other languages would require just a

:- import_module 'System__Data'.

The System.Data namespace contains over 100 different classes.  So
assuming I was doing some complicated database work, I could imagine
that I would need to do 70 imports just to obtain the desired
functionality.  Quite frankly that seems ludicrous to me.

Note that each import only imports the functionality of that class, and
a class in general doesn't have the same amount of functionality as a
mercury module would.  What is particulary galling is that quite often
you only need to use one function from the import to get a different
class from the current class for the next step in the processing chain.

I mentioned this all in a previous email.

http://www.mercury.cs.mu.oz.au/mailing-lists/mercury-developers/mercury-developers.0110/0101.html
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------