[GHC] #10009: type inference regression when faking injective type families

[GHC]

#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