[m-dev.] Module qualification of typeclass methods

[Peter Ross]

On Fri, Nov 16, 2001 at 02:53:06AM +1100, Fergus Henderson wrote:
> On 15-Nov-2001, Peter Ross <peter.ross at miscrit.be> wrote:
> > 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.
> 
> OK, so suppose we have the `:- include' extension proposed earlier.
> Why do we need `:- automatic_include' as well?
> What's wrong with
> 
> 	:- import_module 'System__Data__submodules'.
> 
> where you have
> 
> 	:- module 'System'.
> 	   :- module 'Data'.
> 	      :- include_module 'SqlConnection'.
> 	      :- include_module 'SqlCommand'.
> 	      etc.
> 
> 	      :- module submodules.
> 	      :- interface.
> 	      :- include 'System__Data__SqlConnection'.
> 	      :- include 'System__Data__SqlCommand'.
> 	      etc.
> 	      :- end_module submodules.
> 	   :- end_module 'Data'.
> 	:- end_module 'System'.
> 
The only drawback to this approach is that you lose the sub-module
qualifier.  I would argue that this information is useful.

I would much rather read

    Name = 'System__ServicedComponent__DisposeObject'(O)
    
then

    Name = 'System__submodules__DisposeObject'(O)

or even

    Name = 'System__DisposeObject'(O)

if the `:- include' was located at the top level.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------