#14570: Untouchable error arises from type equality, but not equivalent program with fundeps -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lexi.lambda): Thanks, that’s helpful. I’m content with this ticket being closed, though I am a little interested in the fact that you say they behave differently “by design”. I have two small followup questions: 1. Is there a description of this design choice in existing literature somewhere? I imagine the difference is because fundeps are more restricted than type families, so some generality is traded away for better type inference, but I’m not ''entirely'' sure if that’s true. 2. I have not yet read the paper you linked in detail, though I will—it seems quite interesting. However, more generally, if functional dependencies ''are'' elaborated in a way similar to how type families are, will this design difference be maintained? Or will they act more similarly? I think the conversation in #11534 is likely highly relevant to my root problem here—I had some code that used functional dependencies and ended up with an ''enormous'' number of type variables that needed to be propagated around, despite the fact that many of them were determined by other type variables via functional dependency. I tried switching to type families to eliminate the need to carry around so many variables, and my program stopped typechecking (giving the untouchable error). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/14570#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler