[GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules

[GHC]

#12923: MultiParamTypeClasses + ExtendedDefaultRules
-------------------------------------+-------------------------------------
        Reporter:  amindfv           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Description changed by amindfv:

@@ -44,2 +44,3 @@
- It would be really nice for an EDSL I'm working on to be able to use
- extended defaults here!
+ It would be really nice for an EDSL of mine to be able to use extended
+ defaults here! At the moment my only option has been to use incoherent
+ instances, which has resulted in incoherent behavior...

New description:

 -XExtendedDefaultRules allows us to avoid ambiguity for unannotated
 numeric literals:

 {{{#!hs

 {-# LANGUAGE ExtendedDefaultRules #-}

 data A = A deriving Show

 class ToA a where
    toA :: a -> A

 instance ToA Double where
    toA _ = A

 main = print (toA 5 :: A)

 }}}


 But if we have a multi-param typeclass, -XExtendedDefaultRules doesn't
 help us:


 {{{#!hs

 {-# LANGUAGE ExtendedDefaultRules #-}

 {-# LANGUAGE MultiParamTypeClasses #-}
 {-# LANGUAGE FlexibleInstances #-}

 data A x = A deriving Show

 class ToA a x where
    toA :: a -> A x

 instance ToA Double x where
    toA _ = A

 main = print (toA 5 :: A Bool)

 }}}

 It would be really nice for an EDSL of mine to be able to use extended
 defaults here! At the moment my only option has been to use incoherent
 instances, which has resulted in incoherent behavior...

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12923#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler