[GHC] #8034: Missing ambiguity test for class methods

GHC ghc-devs at haskell.org
Thu Mar 26 13:57:06 UTC 2015


#8034: Missing ambiguity test for class methods
-------------------------------------+-------------------------------------
        Reporter:  simonpj           |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:  7.12.1
       Component:  Compiler (Type    |                 Version:  7.7
  checker)                           |                Keywords:
      Resolution:                    |            Architecture:
Operating System:  Unknown/Multiple  |  Unknown/Multiple
 Type of failure:  None/Unknown      |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by jstolarek):

 I looked at the code today to see if I can fix this together with #6018. A
 quick diagnosis is that the type of class operation is stripped from the
 foralls and thetas so that only tau remains (in Simon's example the type
 `foo :: forall (k :: BOX) (a :: k). C a => F a -> F a` is stripped to `F a
 -> F a`). This tau is passed to ambiguity check but since there are no
 quantified variables the ambiguity check always succeeds. I wonder what
 would be the right strategy here:

   1. In `TcTyClsDecls.checkValidClass` call `checkValidType` (inside
 `check_op`) with some type other than `tau`. I tried a quick hack to add
 the forall variables back to tau (ie. the original type of class operation
 is stripped only from thetas) but there are some corner cases where this
 does not work.

   2. Modify the first case of `TcValidity.check_type` to look for type
 variables under type family applications even if these variables are not
 quantified.

 I'm not sure which of these two is the right way of fixing this so I
 didn't try too hard to implement any of these. If anyone with more
 knowledge can hint me which of these to would be the right way of fixing
 this I think I should be able to write a patch.

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


More information about the ghc-tickets mailing list