Changes between Version 15 and Version 16 of DefaultSuperclassInstances


Ignore:
Timestamp:
Aug 15, 2011 8:42:52 AM (4 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DefaultSuperclassInstances

    v15 v16  
    2525compatibility in relative silence is the motivation for an opt-in
    2626default.
     27
     28== Design goals ==
     29
     30A major design goal is this:
     31
     32 * '''Design goal 1''': a class C can be re-factored into a class C with a superclass S, without disturbing any clients.
     33
     34The difficulty is that if you start with
     35{{{
     36class X a where
     37   f :: ...
     38   g :: ...
     39}}}
     40and lots of clients write instances of `X` and functions that use it:
     41{{{
     42instance X ClientType
     43  f = ...blah...
     44  g = ...blah...
     45
     46foo :: X a => ...
     47foo = ...
     48}}}
     49Now you want to refactor `X` thus:
     50{{{
     51class Y a where
     52  f :: ...
     53class Y a => X a where
     54  g :: ...
     55}}}
     56Design goal 1 is that this change should not force clients to change their code.  Haskell 98 does not satisfy this goal.  In Haskell 98 the client function `foo` is fine unmodified, but the instance declaration would have to be split into two.
    2757
    2858== The proposal ==
     
    187217dangerous tendency to be permanent.
    188218
     219== Other designs ==
     220
     221The [ http://www.haskell.org/haskellwiki/Superclass_defaults superclass default proposal] deals with the question of opt-outs by intead requiring you to opt ''in''.  A `Monad` instance would look like
     222{{{
     223  instance (Applicative m, Monad m) where
     224    (>>=) = ...blah...
     225    (<*)  = ...bleh...
     226}}}
     227where we explicitly ask the compiler to generate an instance of `Applicative`.   The disadvantage is that you have to know to do so, which contracts Design Goal 1.
     228
    189229== Multi-headed instance declarations ==
    190230