[mercury-users] variable parameters in typeclass instances

[Fergus Henderson]

On 03-Nov-1999, Michael Day <mikeday at corplink.com.au> wrote:
> 
> it does not appear to be possible to state the following:
> 
> % everything is an instance of the "pointless" typeclass:
> :- instance pointless(_).
> 
> % everything and int satisfy the "strange_relation" typeclass:
> :- instance strange_relation(int, T).

That is correct, these instance declarations are forbidden
by the current set of restrictions on instance declarations.

> do these declarations have semantic problems that make them undesirable,

Yes.  See below.

Problem number one is that we don't want to allow overlapping
instance declarations.  In the general case, this is difficult
to detect in the presence of separate compilation.  It requires
extra checks at link time (which may mean at dynamic link time,
if you're using dynamic linking).  With our current set of restrictions
on instance declarations, the compiler can use a tricky scheme
based on generating special mangled names for instance declarations
so that with a bit of luck the system linker will detect
duplicate instance declarations in different modules.
This avoids the undesirable cost in terms of performance and
implementation complexity of having a more complicated link-time check.
But if the restrictions on instance declarations were relaxed,
we couldn't use that scheme.

Problem number two is that we (or at least I) want to eventually allow
efficient dynamic type class casts; that is, we want to allow users to
be able to check at runtime whether a type determined at runtime is an
instance of a particular type class, and if so, to call methods of that
type class.  With the current set of restrictions, the process of
checking whether a type is a member of a given type class can be made
roughly linear in the size of the type, I believe.  If you relax the
restrictions, then it's hard to preserve that property.

> or will they be supported in a future version of the compiler?

Possibly, but only if we can find some nice solutions to (or at least
work-around for) the problems.

> The reason I ask is that it would appear to be necessary to do anything
> useful with constructor classes when implementing collections.

You may be right.  And having a nice solution to generic collection
classes is a very important goal.  Finding the optimum point in this
design space is a tricky exercise.  For more details on this, see [1].

[1]
@inproceedings{designspace,
        author =        {Simon Peyton Jones and Mark Jones and Erik Meijer},
        title =         {Type Classes: an exploration of the design space},
        booktitle =     {Proceedings of the Haskell Workshop},
        year =          {1997},
        month =         {June},
        series =        {Lecture Notes in Computer Science},
        publisher =     {Springer Verlag},
        volume =        {788}
}

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------