[m-dev.] Module qualification of typeclass methods

[Fergus Henderson]

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

?

P.S.  I have a couple of new suggestions for better names for `:- include':
`:- open_module'  and `:- open'.  The idea is that you open up the module
and get its contents.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------