Changes between Version 19 and Version 20 of DefaultSuperclassInstances


Ignore:
Timestamp:
Aug 31, 2011 7:20:30 AM (4 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DefaultSuperclassInstances

    v19 v20  
    247247with an explicit instance from the same or a prior module. We could
    248248
    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'''.
    252 
    253 As it stands, we propose option 1 as somehow the principled thing to
    254 do. We acknowledge that it creates an issue with legacy code --- that is, it contradicts
    255 Design Goal 1 ---
    256 precisely because there are plenty of places where we have written the
    257 full stack of instances, often just doing the obvious default thing:
    258 these should be cleaned up, sooner or later.
    259 
    260 Option 3 avoids that
    261 problem but risks perplexity: if I make use of some cool package which
    262 introduces some {{{Foo :: * -> *}}}, I might notice that {{{Foo}}} is
    263 a monad and add a {{{Monad Foo}}} instance in my own code, expecting
    264 the {{{Applicative Foo}}} instance to be generated in concert; to my
    265 horror, I find my code has subtle bugs because the package introduced
    266 a different, non-monadic, {{{Applicative Foo}}} instance which I'm
    267 accidentally using instead.
     249  1. '''Reject this as a duplicate instance declaration''', which indeed it is.  We acknowledge that it creates an issue with legacy code --- that is, it contradicts Design Goal 1 --- precisely because there are plenty of places where we have written the full stack of instances, often just doing the obvious default thing.
     250
     251  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.
     252
     253  3. '''Allow the explicit to supersede the intrinsic default silently'''. This fits with Design Goal 1, but risks perplexity: if I make use of some cool package which introduces some {{{Foo :: * -> *}}}, I might notice that {{{Foo}}} is a monad and add a {{{Monad Foo}}} instance in my own code, expecting the {{{Applicative Foo}}} instance to be generated in concert; to my horror, I find my code has subtle bugs because the package introduced a different, non-monadic, {{{Applicative Foo}}} instance which I'm accidentally using instead.
    268254
    269255There 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.