[GHC] #8450: can't match type Bool with (), but shouldn't have to

[GHC]

#8450: can't match type Bool with (), but shouldn't have to
-------------------------------------+------------------------------------
        Reporter:  dmwit             |            Owner:
            Type:  feature request   |           Status:  new
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.6.3
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by Simon Peyton Jones <simonpj@…>):

 In [changeset:"06aac68dee100b21dc7d304fa90d9baa423507a0/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="06aac68dee100b21dc7d304fa90d9baa423507a0"
 Refactor the constraint solver (again!)

 There are three core changes here:

 a) In the constraint-solver pipeline.
    Given a work-item 'wi', the old scheme was:
       let relevant = getRelevantInerts wi
       interact 'wi' with each constraint in 'relevant'
    Bu now we have a single step
       interact 'wi' with the inert-set

    This turns out to avoid duplication, between getRelevantInerts
    (which needs to know which are relevant) and the interact step.
    Simpler, cleaner.

    This in turn made it sensible to combine the 'spontaneous solve'
    stage into the 'interact with inerts' stage.

 b) Wanteds are no longer used to rewrite wanteds.  See Trac #8450.
    This in turn means that the inert set may have
      - many CFunEqCans with the same LHS
      - many CTyEqCans  with the same LHS
    Hence the EqualCtList in teh domain of inert_eqs and inert_funeqs

 c) Some refactoring of the representation of the inert set,
    Notably inert_dicts and inert_funeqs are indexed by Class and TyCon
    respectively, so we can easily get all the constraints relevant to
    that class or tycon

 There are many knock on effects!  This started as a small job but I
 ended up doing qite a lot.  Some error messages in the test suite
 really did improve as a result of (b)
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8450#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler