Changes between Version 3 and Version 4 of DefaultSuperclassInstances
- Timestamp:
- 03/09/11 16:55:05 (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DefaultSuperclassInstances
v3 v4 84 84 This proposal fits handily with the [wiki:KindFact kind Fact proposal], which allows multiple constraints to be abbreviated by ordinary type synonyms. 85 85 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. 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. Retaining backward compatibility in relative silence is the motivation for an opt-in default. 87 87 88 Oleg 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 }}} 92 which would give us by default 93 {{{ 94 instance Monad m => Applicative (ReaderT r m) where ... 95 }}} 96 thus preventing us adding the more general 97 {{{ 98 instance Applicative m => Applicative (ReaderT r m) where ... 99 }}} 100 The opt-out is crucial, but relatively cheap.
