#10789

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

#10789

sasa bogicevic
Hello,
I am looking at this task https://ghc.haskell.org/trac/ghc/ticket/10789 and need some help on implementing it.
With the help of @int_index I found the place in TcErrors.hs where the error printing occurs  and I think the check
that I need to add will look similar to this one https://github.com/ghc/ghc/blob/master/compiler/typecheck/TcErrors.hs#L1935.

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.

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.

Thanks, Sasa




_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: #10789

Richard Eisenberg-4


On Jun 17, 2018, at 10:01 AM, sasa bogicevic <[hidden email]> 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

RE: #10789

GHC - devs mailing list

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

 

Simon

 

From: ghc-devs <[hidden email]> On Behalf Of Richard Eisenberg
Sent: 18 June 2018 04:21
To: sasa bogicevic <[hidden email]>
Cc: [hidden email]
Subject: Re: #10789

 

 



On Jun 17, 2018, at 10:01 AM, sasa bogicevic <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: #10789

sasa bogicevic
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 <[hidden email]> wrote:

Richard is right. 
 
Let’s attach this useful info to the ticket, rather than ghc-devs.   I’ve done that for this exchange.
 
Simon
 
From: ghc-devs <[hidden email]> On Behalf Of Richard Eisenberg
Sent: 18 June 2018 04:21
To: sasa bogicevic <[hidden email]>
Cc: [hidden email]
Subject: Re: #10789
 
 


On Jun 17, 2018, at 10:01 AM, sasa bogicevic <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs