#8634: Relax functional dependency coherence check ("liberal coverage condition") -----------------------------------+--------------------------------------- Reporter: danilo2 | Owner: Type: feature | Status: new request | Milestone: Priority: high | Version: 7.7 Component: Compiler | Keywords: Resolution: | Architecture: Unknown/Multiple Operating System: | Difficulty: Unknown Unknown/Multiple | Blocked By: Type of failure: None/Unknown | Related Tickets: #1241, #2247, #8356 Test Case: | Blocking: | -----------------------------------+--------------------------------------- Changes (by goldfire): * type: bug => feature request Comment: I have to say I like the idea of `-XDysfunctionalDependencies`. An error in functional dependencies can never make a program "go wrong". Why do I claim this? Because the type safety of GHC Haskell is based on the type safety of Core, GHC's internal, typed language.... and functional dependencies don't exist, at all, in Core. So, perhaps functional dependencies can change exactly what Core is produced, but they can only go from one type-safe Core program to another type-safe Core program. I see something like `-XDysfunctionalDependencies` as quite like `-XIncoherentInstances`. These threaten coherence (the notion that the same instance of a class will be used for the same type(s) in different places) but not type safety. The a power user wants to ignore coherence, maybe that's OK. `-XDysfunctionalDependencies` has another nice benefit: it gives users a quick and dirty way to arbitrarily nudge the type inference engine. Currently, one of the tenets of type inference is that it makes no guesses and performs no search. But with `-XDysfunctionalDependencies` users could provide (perhaps incoherent) hints to the type inference engine, which would allow more programs to type check. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8634#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler