Changes between Version 2 and Version 3 of DefaultSuperclassInstances


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

multi-headed instances

Legend:

Unmodified
Added
Removed
Modified
  • DefaultSuperclassInstances

    v2 v3  
    1 A matter of much consternation, here is a proposal to allow type class declarations to include default instance declarations for their superclasses. It's based on [http://www.haskell.org//pipermail/haskell-prime/2006-August/001587.html Jón Fairbairn's proposal], but it has a more explicit 'off switch' and the policy on corner-cases is rejection. 
     1A matter of much consternation, here is a proposal to allow type class declarations to include default instance declarations for their superclasses. It's based on [http://www.haskell.org//pipermail/haskell-prime/2006-August/001587.html Jón Fairbairn's proposal], but it has a more explicit 'off switch' and the policy on corner-cases is rejection. Credit is due also to the [http://www.haskell.org/haskellwiki/Class_system_extension_proposal class system extension proposal] and its ancestors, in particular, John Meacham's [http://repetae.net/recent/out/classalias.html class alias] proposal. 
    22 
    33We may distinguish two uses of superclasses (not necessarily exclusive). A class can ''widen'' its superclass, extending its interface with new functionality (e.g., adding an inverse to a monoid to obtain a group -- inversion seldom provides an implementation of composition). A class can ''deepen'' its superclass (e.g., an implementation of Traversable f delivers at least enough technology to deliver Foldable f and Functor f). This proposal concerns the latter phenomenon, which is currently such a nuisance that Functor and Applicative are not superclasses of Monad. Nobody wants to be forced to write Functor and Applicative instances, just to access the Monad interface. Moreover, any proposal to refine the library by splitting a type class into depth-layers is (rightly!) greeted with howls of protest as an absence of superclass instances gives rise to breakage of the existing codebase. 
     
    6969or indeed to turn off all the defaults and provide a standalone Functor instance. 
    7070 
     71  * while we're about it, to allow multi-headed instance declarations for class-disjoint conjunctions, with the same semantics for constraint duplication and method distribution as for the defaults, so 
     72{{{ 
     73    instance S => (C x, C' x) where 
     74      methodOfC  = ... 
     75      methodOfC' = ... 
     76}}} 
     77is short for 
     78{{{ 
     79    instance S => C x where 
     80      methodOfC  = ... 
     81    instance S => C' x where 
     82      methodOfC' = ... 
     83}}} 
     84This proposal fits handily with the [wiki:KindFact kind Fact proposal], which allows multiple constraints to be abbreviated by ordinary type synonyms. 
     85 
     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. 
     87