Changes between Version 3 and Version 4 of DefaultSuperclassInstances


Ignore:
Timestamp:
Mar 10, 2011 12:55:05 AM (3 years ago)
Author:
pigworker
Comment:

remark about transformers

Legend:

Unmodified
Added
Removed
Modified
  • DefaultSuperclassInstances

    v3 v4  
    8484This proposal fits handily with the [wiki:KindFact kind Fact proposal], which allows multiple constraints to be abbreviated by ordinary type synonyms. 
    8585 
    86 Default superclass instances are implemented in the [http://personal.cis.strath.ac.uk/~conor/pub/she/superclass.html Strathclyde Haskell Enhancement]. They should enable some tidying of the library, with relatively few tears. Moreover, they should allow us to deepen type class hierarchies as we learn. 
     86Default superclass instances are implemented in the [http://personal.cis.strath.ac.uk/~conor/pub/she/superclass.html Strathclyde Haskell Enhancement]. They should enable some tidying of the library, with relatively few tears. Moreover, they should allow us to deepen type class hierarchies as we learn. Retaining backward compatibility in relative silence is the motivation for an opt-in default. 
    8787 
     88Oleg and others note: just because you can make default instances, they are not always the instances you want. A key example is 
     89{{{ 
     90    instance Monad m => Monad (ReaderT r m) where ... 
     91}}} 
     92which would give us by default 
     93{{{ 
     94    instance Monad m => Applicative (ReaderT r m) where ... 
     95}}} 
     96thus preventing us adding the more general 
     97{{{ 
     98    instance Applicative m => Applicative (ReaderT r m) where ... 
     99}}} 
     100The opt-out is crucial, but relatively cheap.