#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