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. Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of | Malcolm Wallace | Sent: 20 November 2006 12:06 | To: haskell-prime@haskell.org | 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: | | http://hackage.haskell.org/trac/haskell-prime/wiki/Defaulting | | 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@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime