[GHC] #9569: Tuple constraints don't work right

GHC ghc-devs at haskell.org
Fri Nov 21 13:02:51 UTC 2014


#9569: Tuple constraints don't work right
-------------------------------------+-------------------------------------
              Reporter:  simonpj     |            Owner:
                  Type:  bug         |           Status:  new
              Priority:  normal      |        Milestone:
             Component:  Compiler    |          Version:  7.8.2
            Resolution:              |         Keywords:
      Operating System:              |     Architecture:  Unknown/Multiple
  Unknown/Multiple                   |       Difficulty:  Unknown
       Type of failure:              |       Blocked By:
  None/Unknown                       |  Related Tickets:
             Test Case:              |
  polykinds/T9569,                   |
  typecheck/should_compile/T9569a    |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

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

 In [changeset:"b6855422fd532e5988fc98764c5cc47acbefbfb8/ghc"]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="b6855422fd532e5988fc98764c5cc47acbefbfb8"
 Implement full co/contra-variant subsumption checking (fixes Trac #9569)

 This is a pretty big patch, but which substantially iproves the
 subsumption
 check.  Trac #9569 was the presenting example, showing how type inference
 could
 depend rather delicately on eta expansion.  But there are other less
 exotic
 examples; see Note [Co/contra-variance of subsumption checking] in
 TcUnify.

 The driving change is to TcUnify.tcSubType.  But also

 * HsWrapper gets a new constructor WpFun, which behaves very like CoFun:
        if     wrap1 :: exp_arg <= act_arg
               wrap2 :: act_res <= exp_res
        then   WpFun wrap1 wrap2 : (act_arg -> arg_res) <= (exp_arg ->
 exp_res)

 * I generalised TcExp.tcApp to call tcSubType on the result,
   rather than tcUnifyType.  I think this just makes it consistent
   with everything else, notably tcWrapResult.

 As usual I ended up doing some follow-on refactoring

 * AmbigOrigin is gone (in favour of TypeEqOrigin)
 * Combined BindPatSigCtxt and PatSigCxt into one
 * Improved a bit of error message generation
 }}}

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


More information about the ghc-tickets mailing list