Changes between Version 18 and Version 19 of DefaultSuperclassInstances


Ignore:
Timestamp:
Aug 31, 2011 7:16:15 AM (3 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DefaultSuperclassInstances

    v18 v19  
    185185So the above instance would generate an intrinsic instance for `Applicative` but not for `Functor`. 
    186186 
     187See below for more about the opt-out mechanism. 
     188 
    187189=== Details === 
    188190 
     
    210212=== The design of the opt-out mechanism === 
    211213 
    212 The [ 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 
    213 {{{ 
    214   instance (Functor T, Applicative T, Monad T) where 
    215     (>>=) = ...blah... 
    216     return = ...bleh... 
    217 }}} 
    218 where we explicitly ask the compiler to generate an instance of `Applicative T` and `Functor T`.   The disadvantage is that you have to know to do so, which contradicts Design Goal 1. 
    219  
    220214Jón's proposal had a more subtle opt-out policy, namely that an 
    221 intrinsic superclass can be quietly pre-empted by an instance for the 
     215intrinsic superclass can be '''silently pre-empted''' by an instance for the 
    222216superclass from a prior or the present module.  
    223217For example, instead of  
     
    247241intrinsic instances arising from multiple intrinsic superclasses (e.g., 
    248242`Traversable` and `Monad` giving competing `Functor` instances), so some 
    249 explicit form is required. The question for us, then, is what should 
     243explicit `hiding` form is required even under the "silent pre-emption" plan.  
     244 
     245The question for us, then, is what should 
    250246happen if an intrinsic superclass not explicitly hidden were to clash 
    251247with an explicit instance from the same or a prior module. We could 
    252248 
    253   1. Reject this as a duplicate instance declaration, which indeed it is. 
    254   2. Allow the explicit to supersede the intrinsic default, but issue a warning suggesting to either remove the explicit instance or add an explicit opt-out, or 
    255   3. Allow the explicit to supersede the intrinsic default silently. 
     249  1. '''Reject this as a duplicate instance declaration''', which indeed it is. 
     250  2. '''Allow the explicit to supersede the intrinsic default, but issue a warning''' suggesting to either remove the explicit instance or add an explicit opt-out, or 
     251  3. '''Allow the explicit to supersede the intrinsic default silently'''. 
    256252 
    257253As it stands, we propose option 1 as somehow the principled thing to 
    258 do. We acknowledge that it creates an issue with legacy code, 
     254do. We acknowledge that it creates an issue with legacy code --- that is, it contradicts 
     255Design Goal 1 --- 
    259256precisely because there are plenty of places where we have written the 
    260257full stack of instances, often just doing the obvious default thing: 
     
    268265horror, I find my code has subtle bugs because the package introduced 
    269266a different, non-monadic, {{{Applicative Foo}}} instance which I'm 
    270 accidentally using instead. Option 2 is certainly worth considering as 
    271 a pragmatic transitional compromise, although the 'transitional' has a 
    272 dangerous tendency to be permanent. 
     267accidentally using instead.  
     268 
     269There is considerable support in the [http://www.haskell.org/pipermail/glasgow-haskell-users/2011-August/020730.html email discussion thread] for Option 2 or 3, on the grounds that Option 1 contradicts Design Goal 1.   
     270 
     271Perhaps Option 2 is the pragmatic choice. 
     272 
     273=== Opting in rather than out === 
     274 
     275The [ 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 
     276{{{ 
     277  instance (Functor T, Applicative T, Monad T) where 
     278    (>>=) = ...blah... 
     279    return = ...bleh... 
     280}}} 
     281where we explicitly ask the compiler to generate an instance of `Applicative T` and `Functor T`.   The disadvantage is that you have to know to do so, which contradicts Design Goal 1. 
    273282 
    274283== Multi-headed instance declarations ==