#10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: 7.10.2 => 7.12.1 Comment: Sigh, so unfortunately I've spent some more time futzing around with the patch, and I just don't think it can be merged in a sensible way without even more work. And even though the work seems doable I'm just very averse to the risk of it at this point, I'm afraid. I think I've even got the redundant superclass constraint patch building, but I'm just not sure it's worth it. This is most certainly a regression but realistically I'm not sure how much it will come up. There have been three users who want it (Adam, Adam and Wolfgang) and who have reported it as "please fix" AFAICS, but as Simon originally said it shouldn't affect much code, and we didn't hold the original release up for this bug anyway. Unless there is overwhelming evidence this is a common and game breaking bug that has cropped up in practice (which I'm really not sure of!), I've decided to leave this out of the release candidate, and subsequently, the final release. Wolfgang, I sincerely apologize for this as it is not an easy thing for you to work around in your paper or library, and I understand it's suboptimal (and even frustrating). But I would rather ship the significant improvements we have now for even more users to make things better. I'm sorry this one missed the boat. FTR, I tried merging in the redundant superclass constraints patch (since the improvement patch was dependent on it), which on its own has actually proved to be a bit difficult. But I'm just getting more risk aversive to this - these patches also have tons of knock on changes like error messages (which are merely a hassle), but even worse, further bugfixes of their own in more patches later - which I'd have to track, adopt and make sure are fixed. And even then, _none_ of these patches are in a released compiler - there's been churn here from Simon recently. It's not clear when to _stop_. So it's impossible to tell if I should pick up *just* that patch, or that patch + 10 others because the intermediate states are all variously broken, or that patch + the next 5 'bugfix + refactor' patches are good enough. Once I've pushed these two, I'm just not sure how *many more* I'll have to push. So I'm moving this to 7.12.1 and closing it. Simon, please re-open if you think there's more work to be done here. Again, I apologize for the lead- on with this one, but after getting closer and closer, it simply does not seem worth it I'm afraid. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10009#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler