#15927: Weird interaction between fundeps and overlappable instances -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 15632 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:2 Darwin226]:
I'm sorry if you addressed this in your comment and I'm just not getting it, but note that I'm not just declaring `f` with and unsatisfyable constraint. I'm also able to satisfy it!
Sorry if I was a bit oblique. I'm totally impressed that works. I would never have thought of trying it.
So are you saying that this behavior can be relied on? Is my code likely
to get broken in newer GHC versions? Good questions! I'll leave GHC HQ to answer definitively. Here's my take: This behaviour has been around since at least 2004: it's exploited in the HList paper, but the authors felt very uncomfortable about it. If you read #10675, SPJ describes GHC's behaviour as "bogus" and not supported by any of the academic theory around FunDeps -- including the 2006 paper of which he is a co-author. So yes your code might break in future releases, except ... There is a lot of code out there that exploits this loophole. (Usually with overlapping instances + FunDeps, but not exactly your ruse of putting contrary constraints on the same function.) So as my comments conclude on #10675, 'fixing' this will probably cause howls of outrage/break a fair amount of code. AFAICT nobody at GHC HQ is interested in anything around FunDeps/Overlaps, and hasn't been for a long time. So they will probably say: a) No, that behaviour can't be relied on. b) We're not going to 'fix' it, so you can get away with it for probably another decade. c) Use Closed Type Families instead of the FunDep, and make `MyState` a single parameter typeclass. I was going to try your code in my version of Haskell that (I think) takes a more principled approach. Just hang on a bit. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15927#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler