Typeclass resolution errors quite puzzling

Tom Ellis

15 Aug 2016 15 Aug '16

9:26 a.m.

Here's a program with an odd error message (GHC 8.0.1): data A a = A a deriving Eq data B = B main :: IO () main = print (A B == A B) test/main.hs:5:15: error: • No instance for (Eq B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) I get an error about Eq B even though it's Eq A that is manifestly required at the call site. This error is odder when A and B are defined far away from the use of '=='. This is even odder: data A a = A a data B = B instance Ord a => Eq (A a) where main :: IO () main = print (A B == A B) test/main.hs:7:15: error: • No instance for (Ord B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) Now not only is the type puzzling (B instead of A) but the *class* is puzzling (Ord instead of Eq). This occurred to me in practice because 'Data.Graph.Inductive.PatriciaTree.Gr' has '(Eq a, Ord b) => Eq (Gr a b)'. It would have been a lot more helpful to see * No instance for (Ord B) * arising from (Eq A) * arising from the use of '==' Does anyone agree with me that GHC should produce the full trace when it fails to resolve instances rather than just the proximal failure? Tom

Show replies by date

Damian Nadales

15 Aug 15 Aug

9:33 a.m.

On Mon, Aug 15, 2016 at 3:26 PM, Tom Ellis wrote:

...

Here's a program with an odd error message (GHC 8.0.1):

data A a = A a deriving Eq data B = B

main :: IO () main = print (A B == A B)

test/main.hs:5:15: error: • No instance for (Eq B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B)

I would expect this error, since B does not implement equality. Maybe you're expecting Haskell to automatically derive an Eq B instance, but that is not the behavior I would want, since data definitions could implicitly define instances for other data types. Is there any reason why you don't define: data B = B deriving Eq?

...

I get an error about Eq B even though it's Eq A that is manifestly required at the call site. This error is odder when A and B are defined far away from the use of '=='.

This is even odder:

data A a = A a data B = B

instance Ord a => Eq (A a) where

main :: IO () main = print (A B == A B)

test/main.hs:7:15: error: • No instance for (Ord B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B)

Now not only is the type puzzling (B instead of A) but the *class* is puzzling (Ord instead of Eq). This occurred to me in practice because 'Data.Graph.Inductive.PatriciaTree.Gr' has '(Eq a, Ord b) => Eq (Gr a b)'.

It would have been a lot more helpful to see

* No instance for (Ord B) * arising from (Eq A) * arising from the use of '=='

Does anyone agree with me that GHC should produce the full trace when it fails to resolve instances rather than just the proximal failure?

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Tom Ellis

9:35 a.m.

On Mon, Aug 15, 2016 at 03:33:23PM +0200, Damian Nadales wrote:

...

On Mon, Aug 15, 2016 at 3:26 PM, Tom Ellis wrote:

...
Here's a program with an odd error message (GHC 8.0.1):

data A a = A a deriving Eq data B = B

main :: IO () main = print (A B == A B)

test/main.hs:5:15: error: • No instance for (Eq B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B)

I would expect this error, since B does not implement equality. Maybe you're expecting Haskell to automatically derive an Eq B instance, but that is not the behavior I would want, since data definitions could implicitly define instances for other data types.

Is there any reason why you don't define: data B = B deriving Eq?

My complaint is about the confusing error message, not the failure to type check.

Francesco Ariis

9:38 a.m.

On Mon, Aug 15, 2016 at 02:35:15PM +0100, Tom Ellis wrote:

...

My complaint is about the confusing error message, not the failure to type check.

For reference, feeding that program to Hugs (which I usually find a bit better in terms of error reporting) leads to: ERROR "prova.hs":5 - Instance of Eq B required for definition of main Slightly clearer but not much. I don't have UHC handy to test its error messages!

Tom Ellis

9:48 a.m.

On Mon, Aug 15, 2016 at 03:38:45PM +0200, Francesco Ariis wrote:

...

On Mon, Aug 15, 2016 at 02:35:15PM +0100, Tom Ellis wrote:

...
My complaint is about the confusing error message, not the failure to type check.

For reference, feeding that program to Hugs (which I usually find a bit better in terms of error reporting) leads to:

ERROR "prova.hs":5 - Instance of Eq B required for definition of main

Slightly clearer but not much. I don't have UHC handy to test its error messages!

I find that message equally puzzling. It seems to me that the most helpful message would have to mention that Eq B is required to satisfy Eq A.

Francesco Ariis

9:51 a.m.

On Mon, Aug 15, 2016 at 02:48:58PM +0100, Tom Ellis wrote:

...

I find that message equally puzzling. It seems to me that the most helpful message > would have to mention that Eq B is required to satisfy Eq A.

Time to file a feature request then! :) https://ghc.haskell.org/trac/ghc/wiki/ReportABug

Tom Ellis

10 a.m.

On Mon, Aug 15, 2016 at 03:51:33PM +0200, Francesco Ariis wrote:

...

On Mon, Aug 15, 2016 at 02:48:58PM +0100, Tom Ellis wrote:

...
I find that message equally puzzling. It seems to me that the most helpful message > would have to mention that Eq B is required to satisfy Eq A.

Time to file a feature request then! :) https://ghc.haskell.org/trac/ghc/wiki/ReportABug

I shall if I get some confirmation that this is a sane thing to want!

Malcolm Wallace

10:40 a.m.

I have to say that I don't find the original error message confusing at all. It points directly to the missing instance, namely Eq B. If you add an instance for Eq B, the program will work. It is no surprise that the instance Eq A is not mentioned, because there is a perfectly valid instance for it already, and it contains no error. The /expression/ pointed to by the error message has A values in it, but the error message is correctly steering you away from considering the As, and telling you to consider the Bs instead. Regards, Malcolm On 15 Aug 2016, at 15:00, Tom Ellis wrote:

...

On Mon, Aug 15, 2016 at 03:51:33PM +0200, Francesco Ariis wrote:

...
On Mon, Aug 15, 2016 at 02:48:58PM +0100, Tom Ellis wrote:

...
I find that message equally puzzling. It seems to me that the most helpful message > would have to mention that Eq B is required to satisfy Eq A.

Time to file a feature request then! :) https://ghc.haskell.org/trac/ghc/wiki/ReportABug

I shall if I get some confirmation that this is a sane thing to want! _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Tom Ellis

10:50 a.m.

On Mon, Aug 15, 2016 at 03:40:46PM +0100, Malcolm Wallace wrote:

...

It is no surprise that the instance Eq A is not mentioned, because there is a perfectly valid instance for it already, and it contains no error.

I disagree. There is no valid instance for Eq (A B), because all that the compiler knows is that 'Eq B => Eq (A B)', and there is no 'Eq B'. There are two separate issues here. 1. The reason the compilation fails is that there is no instance 'Eq (A B)'. 2. The reason there is no instance 'Eq (A B)' is that there is no instance 'Eq B'. In my opinion it would be most helpful to the user to mention both 1 and 2. In fact it's likely to be very confusing if you don't mention both of them! Tom

Tom Ellis

10:58 a.m.

On Mon, Aug 15, 2016 at 03:50:03PM +0100, Tom Ellis wrote:

...

On Mon, Aug 15, 2016 at 03:40:46PM +0100, Malcolm Wallace wrote:

...
It is no surprise that the instance Eq A is not mentioned, because there is a perfectly valid instance for it already, and it contains no error.

I disagree.

There is no valid instance for Eq (A B), because all that the compiler knows is that 'Eq B => Eq (A B)', and there is no 'Eq B'.

There are two separate issues here.

1. The reason the compilation fails is that there is no instance 'Eq (A B)'.

2. The reason there is no instance 'Eq (A B)' is that there is no instance 'Eq B'.

In my opinion it would be most helpful to the user to mention both 1 and 2. In fact it's likely to be very confusing if you don't mention both of them!

By the way, I agree with the spirit of this:

...

It points directly to the missing instance, namely Eq B. If you add an instance for Eq B, the program will work ... the error message is correctly steering you away from considering the As, and telling you to consider the Bs instead.

but I don't see why the compiler shouldn't be even *more* helpful in its steering and explain how and why it came to need 'Eq B'. Tom

Bertram Felgenhauer

1:07 p.m.

Tom Ellis wrote:

...

On Mon, Aug 15, 2016 at 03:40:46PM +0100, Malcolm Wallace wrote:

...
It is no surprise that the instance Eq A is not mentioned, because there is a perfectly valid instance for it already, and it contains no error.

I disagree.

There is no valid instance for Eq (A B), because all that the compiler knows is that 'Eq B => Eq (A B)', and there is no 'Eq B'.

There are two separate issues here.

1. The reason the compilation fails is that there is no instance 'Eq (A B)'.

2. The reason there is no instance 'Eq (A B)' is that there is no instance 'Eq B'.

I believe the the missing Eq instance for B is the more useful bit of information of these two, but I wouldn't mind an explanation of the simplification steps that the compiler made to discover it. I'm a bit worried though that such an explanation may be very long, and I expect that it's not trivial to extract this information from ghc's constraint based type checker. (In principle, -ddump-tc-trace prints all this information, but it's far too verbose and cluttered by ghc internal identifiers.) Cheers, Bertram

David Feuer

1:26 p.m.

For what it's worth, I also think it would be really useful to get a trace of the constraint simplification when there's a resolution failure. Unification could make some bits hard to understand, but anything would be better than nothing. On Aug 15, 2016 10:50 AM, "Tom Ellis" < tom-lists-haskell-cafe-2013@jaguarpaw.co.uk> wrote:

...

On Mon, Aug 15, 2016 at 03:40:46PM +0100, Malcolm Wallace wrote:

...
It is no surprise that the instance Eq A is not mentioned, because there is a perfectly valid instance for it already, and it contains no error.

I disagree.

There is no valid instance for Eq (A B), because all that the compiler knows is that 'Eq B => Eq (A B)', and there is no 'Eq B'.

There are two separate issues here.

1. The reason the compilation fails is that there is no instance 'Eq (A B)'.

2. The reason there is no instance 'Eq (A B)' is that there is no instance 'Eq B'.

In my opinion it would be most helpful to the user to mention both 1 and 2. In fact it's likely to be very confusing if you don't mention both of them!

Tom _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

3200

Age (days ago)

3200

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Bertram Felgenhauer
Damian Nadales
David Feuer
Francesco Ariis
Malcolm Wallace
Tom Ellis