[GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition")

[GHC]

#8634: Relax functional dependency coherence check ("liberal coverage condition")
-------------------------------------+-------------------------------------
        Reporter:  danilo2           |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler (Type    |              Version:  7.7
  checker)                           |
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #1241, #2247,     |  Differential Rev(s):  Phab:D69
  #8356, #9103, #9227                |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by AntC):

 Replying to [comment:34 danilo2]:

 Hi Wojciech/all, this ticket seems to have been stalled for some time. Is
 it still causing anybody pain? Did something get better in a later
 release?

 I've tried to wade through the comments, but I'm left very unsure what the
 proposal is, or what are the use cases. To look at your proposed test
 code. (https://phabricator.haskell.org/D69 has a smaller example.) Either
 the code is not actually testing for how D69 is to change behaviour, or
 there's already a (simpler?) way to achieve it.

 > ... I will try to put here another one, a little more complex:
 > {{{#!haskell
 > {-# LANGUAGE NoMonomorphismRestriction #-}
 > {-# LANGUAGE MultiParamTypeClasses #-}
 > {-# LANGUAGE FunctionalDependencies #-}
 > {-# LANGUAGE FlexibleInstances #-}
 > {-# LANGUAGE DysfunctionalDependencies #-}
 >
 > class Property a b | a -> b where
 >    property :: a -> b
 >
 > data X = X
 > data Y = Y
 >
 > instance Monad m => Property X Y where
 >     property _ = Y
 >
 > instance Monad m => Property Y (m Int) where
 >     property _ = return 5
 >
 > main = do
 >     let f = property $ property X
 > }}}

 Your O.P. included a Monad as one of the params to the class, and it was
 determined from the first param. Here the Monad seems to materialise out
 of thin air. In your first `instance` it's not even used. In the second
 instance it seems that could be any Monad at all(?)

 If your class is usually non-monadic, but you happen to use method
 `property` inside monadic code, you could just wrap the call in `return`.
 If your class is usually monadic, but you happen to need `property` in a
 non-monadic context, you could wrap it in the the `Identity` monad and
 extract the result(?)

 See my comment:70 above/examples. With `UndecidableInstances` there seems
 to be plenty of ways to evade the Consistency Condition.

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