Re: #10789

Thanks! So probably not good issue for the first PR but I will not be intimidated by the complexity. Sasa

On 18 Jun 2018, at 10:41, Simon Peyton Jones wrote:

Richard is right.

Let’s attach this useful info to the ticket, rather than ghc-devs. I’ve done that for this exchange. https://ghc.haskell.org/trac/ghc/ticket/10789#comment:18 https://ghc.haskell.org/trac/ghc/ticket/10789#comment:18

Simon

From: ghc-devs mailto:ghc-devs-bounces@haskell.org> On Behalf Of Richard Eisenberg Sent: 18 June 2018 04:21 To: sasa bogicevic mailto:brutallesale@gmail.com> Cc: ghc-devs@haskell.org mailto:ghc-devs@haskell.org Subject: Re: #10789

On Jun 17, 2018, at 10:01 AM, sasa bogicevic mailto:brutallesale@gmail.com> wrote:

So I guess that we need to check if one of the kinds of two types we are comparing defaults to * (or Type if you will) and then add new warning that will be more descriptive as to why the failure happened. Maybe there is a way to check if what we are comparing are actually type families so that would make the job easier I guess.

I don't think the problem is particular to `Type` or defaulting. Instead, the problem is when one of the two mismatched types is a type family application where the type family has equations that pattern-match on an invisible parameter, and it's that invisible-parameter matching that's gone awry. Now that I think about it, detecting these particular conditions might be tricky: you might need to edit code in FamInstEnv that does type family equation lookup to return diagnostic information if a match fails. (I would look at reduceTyFamApp_maybe, and perhaps it can return something more interesting than Nothing in the failure case.)

Richard Eisenberg offered some help on this but I am not sure how to grab hold of him so I'd appreciate any help I could get.

Just email! :)

Thanks for looking into this! Richard