Simon Peyton-Jones simonpj at
Mon Nov 20 09:49:21 EST 2006

remember that defaulting does not happen class-by-class at the moment. If you have

        (Eq a, Fractional a)

where 'a' is unconstrained, the current rules pick the first type T in the defaulting list that satisfies all the constraints (Eq T, Fractional T)

I don't know what would that would mean if Eq had a different defaulting list than Fractional, as you propose.

Another issue that Haskell' needs to address is what defaulting means when you have multi-parameter type classes.


| -----Original Message-----
| From: haskell-prime-bounces at [mailto:haskell-prime-bounces at] On Behalf Of
| Malcolm Wallace
| Sent: 20 November 2006 12:06
| To: haskell-prime at
| Subject: defaults
| Prompted by recent discussion on the Hat mailing list about the problems
| of type-defaulting, I have added two new proposals for this issue to the
| Haskell-prime wiki at:
| The main new proposal is a different way of specifying defaults, which
| includes the name of the class being defaulted (thus allowing
| user-defined classes to play this game), but unlike the original
| proposal, permits only one type to be specified per class.  The rules
| are therefore also simpler, whilst still (I believe) capturing the
| useful cases.
| A secondary proposal is to generalise defaults from having module-local
| scope, to global scope.  This would allow library authors to capture the
| intended behaviour of their own classes and types, without bothering the
| library users.   (Also, whilst removing module-local redefinition of
| defaults, the proposal would instead permit function-local
| re-definition.)  I am less convinced of the need for this proposal, but
| in the spirit of exploring the design space, I thought it worth bringing
| up.
| Regards,
|     Malcolm
| _______________________________________________
| Haskell-prime mailing list
| Haskell-prime at

More information about the Haskell-prime mailing list