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

[GHC]

#8634: Relax functional dependency coherence check ("liberal coverage condition")
-------------------------------------+-------------------------------------
        Reporter:  danilo2           |                Owner:
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.2.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 dfeuer):

 I think Simon's suggestion in [comment:30 comment 30] of a different
 notation for not-really-functional suggestions is much better than the
 per-instance pragma. Thus

 {{{#!hs
 class Foo a b c | a b -> c, a c ~> b
 }}}

 would clearly indicate that `a` and `b` must solidly determine `c`, but
 that the type checker is free to guess `b` based on `a` and `c` when it
 thinks it needs to.

 One thing to note is that, as shown in
 [http://stackoverflow.com/a/35413064/1477667 this answer] to a related
 question I asked recently, functional dependencies are ''already''
 dysfunctional. In particular, module import diamonds can lead to
 undetected fundep violations.

 I'd personally like to see the following:

 1. Add a "soft dependency" `~>` as described.
 2. Plug the module diamond loophole.
 3. Translate fundeps into type families in core, so that `class Bar a b |
 a -> b` will let me write `funBar :: (Bar a b, Bar a b') => b :~: b'`. The
 translation could even be ''exposed'' by an extension, I imagine, so that
 `__Bar_1_DETERMINES_2` (or whatever) would be a usable type family.

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