type error formatting

Evan Laforge

23 Oct 2015 23 Oct '15

10:48 p.m.

Here's a typical simple type error from GHC: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record: Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) Or alternately, taking up a bit more vertical space: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] ----------------------------- In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ ----------------------------- Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) Thoughts? It seems simple enough that I could do myself, but of course not without buy-in.

Attachments:

attachment.html (text/html — 7.5 KB)

Show replies by date

Edward Z. Yang

23 Oct 23 Oct

10:50 p.m.

I think this is quite a reasonable suggestion. Edward Excerpts from Evan Laforge's message of 2015-10-23 19:48:07 -0700:

...

Here's a typical simple type error from GHC:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record:

Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Or alternately, taking up a bit more vertical space:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])]

Joachim Breitner

24 Oct 24 Oct

4:17 a.m.

Hi, thanks for starting this discussion, and I agree with your suggestion. Maybe we can brainstorm some more fine refinements. Given that our error message are on the rather verbose side, maybe there is detail that can be omitted. For example in

...

Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

do we really need to know what file these come from? I guess, in all but very obscure cases (or really all) they are from the same file. So why not omit the filename? Also, unless the programmer is doing weird things with shadowing, is the "bound at" information really valuable? I’d say no: Usually, the programmer knows his bindings, and even if not, she will not have any problems finding the right binding. So I suggest to drop the "bound at" line unless the binding is from a different file.

...

This would make this section much easier to parse and grasp visually.

Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Malcolm Wallace

5:08 a.m.

On 24 Oct 2015, at 09:17, Joachim Breitner wrote:

...

For example in

...
Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Also, unless the programmer is doing weird things with shadowing, is the "bound at" information really valuable? I’d say no: Usually, the programmer knows his bindings, and even if not, she will not have any problems finding the right binding.

As someone who spends a lot of time maintaining code that I did not write, I have to say that it is not enough that the "programmer knows his bindings". She might, but I do not. This kind of helpful signposting of exactly what file + linenumber + character position to look at, is really useful for someone who is not familiar with the code. Regards, Malcolm

Joachim Breitner

5:29 a.m.

Hi, Am Samstag, den 24.10.2015, 10:08 +0100 schrieb Malcolm Wallace:

...

On 24 Oct 2015, at 09:17, Joachim Breitner wrote:

...
For example in

...
Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Also, unless the programmer is doing weird things with shadowing, is the "bound at" information really valuable? I’d say no: Usually, the programmer knows his bindings, and even if not, she will not have any problems finding the right binding.

As someone who spends a lot of time maintaining code that I did not write, I have to say that it is not enough that the "programmer knows his bindings". She might, but I do not. This kind of helpful signposting of exactly what file + linenumber + character position to look at, is really useful for someone who is not familiar with the code.

sure, there is a trade off. But the file can by default to be assumed to be the file of the error. And are you really going to note the line number and go to that line, instead of just issuing /syllables? When error messages reach the vertical size of a terminal window, the benefit of adding such details diminishes. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Roman Cheplyaka

6:07 a.m.

I have the same issue with the current error messages. I think these are all good ideas. On 10/24/2015 05:48 AM, Evan Laforge wrote:

...

Here's a typical simple type error from GHC:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record:

Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Or alternately, taking up a bit more vertical space:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] ----------------------------- In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ ----------------------------- Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Thoughts? It seems simple enough that I could do myself, but of course not without buy-in.

Ryan Trinkle

11:30 a.m.

This looks like an improvement to me. I love the idea of a visual demarcation between sections, too; the bullets seem like a good choice there (the horizontal lines seem like they'd take up more space). Ryan On Sat, Oct 24, 2015 at 6:07 AM, Roman Cheplyaka wrote:

...

I have the same issue with the current error messages. I think these are all good ideas.

On 10/24/2015 05:48 AM, Evan Laforge wrote:

...
Here's a typical simple type error from GHC:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record:

Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Or alternately, taking up a bit more vertical space:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] ----------------------------- In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ ----------------------------- Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Thoughts? It seems simple enough that I could do myself, but of course not without buy-in.

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Simon Peyton Jones

3:50 p.m.

I’m all for it. Can advise. (Make a ticket.) Thanks! Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Evan Laforge Sent: 24 October 2015 03:48 To: GHC users Subject: type error formatting Here's a typical simple type error from GHC: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record: Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) Or alternately, taking up a bit more vertical space: Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] ----------------------------- In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ ----------------------------- Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) Thoughts? It seems simple enough that I could do myself, but of course not without buy-in.

Evan Laforge

4:14 p.m.

Ok, ticket created. I'll go see how much I can figure out on my own. https://ghc.haskell.org/trac/ghc/ticket/11014 WRT the "bound at" bits in "relevant bindings", I have no strong opinion. What about omitting them if they are in the same file as the main error? Or maybe they always are? I'm not totally clear how it chooses which bindings are relevant. On Sat, Oct 24, 2015 at 12:50 PM, Simon Peyton Jones wrote:

...

I’m all for it. Can advise. (Make a ticket.)

Thanks!

Simon

*From:* Glasgow-haskell-users [mailto: glasgow-haskell-users-bounces@haskell.org] *On Behalf Of *Evan Laforge *Sent:* 24 October 2015 03:48 *To:* GHC users *Subject:* type error formatting

Here's a typical simple type error from GHC:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record:

Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Or alternately, taking up a bit more vertical space:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])]

----------------------------- In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

----------------------------- Relevant bindings include

syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Thoughts? It seems simple enough that I could do myself, but of course not without buy-in.

MigMit

4:30 p.m.

At the very least, "bound at" should help IDEs (Emacs in particular) show exactly the right places.

...

On 24 Oct 2015, at 22:14, Evan Laforge wrote:

Ok, ticket created. I'll go see how much I can figure out on my own.

https://ghc.haskell.org/trac/ghc/ticket/11014

WRT the "bound at" bits in "relevant bindings", I have no strong opinion. What about omitting them if they are in the same file as the main error? Or maybe they always are? I'm not totally clear how it chooses which bindings are relevant.

On Sat, Oct 24, 2015 at 12:50 PM, Simon Peyton Jones wrote: I’m all for it. Can advise. (Make a ticket.)

Thanks!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Evan Laforge Sent: 24 October 2015 03:48 To: GHC users Subject: type error formatting

Here's a typical simple type error from GHC:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record:

Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Or alternately, taking up a bit more vertical space:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])]

----------------------------- In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

----------------------------- Relevant bindings include

syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Thoughts? It seems simple enough that I could do myself, but of course not without buy-in.

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Joachim Breitner

25 Oct 25 Oct

4:21 p.m.

Hi, Am Samstag, den 24.10.2015, 13:14 -0700 schrieb Evan Laforge:

...

WRT the "bound at" bits in "relevant bindings", I have no strong opinion. What about omitting them if they are in the same file as the main error? Or maybe they always are? I'm not totally clear how it chooses which bindings are relevant.

take one step at a time, and fix the issue you are having within #11014. Once that is through and merged, then (or in parallel to) trying to trim down the bound-at messages can be attempted. Am Samstag, den 24.10.2015, 22:30 +0200 schrieb MigMit:

...

At the very least, "bound at" should help IDEs (Emacs in particular) show exactly the right places.

an IDE that offers such a deep integration will hopefully not parse data meant for human consumption. We have had this discussion before (in the context of avoiding or merging multiple instances of the same error message, such as “foo not in scope”), and I continue to argue that the error messages printed by default should be tailored for the human reader. IDEs should ideally make use of something based on the GHC API. If that is not possible, then I’d advocate a flag, say "-fverbose-error- messages" or similar that includes all detail that might be relevant for an IDE, and maybe even in a nicer-to-parse format. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

MigMit

4:30 p.m.

...

On 25 Oct 2015, at 21:21, Joachim Breitner wrote:

Am Samstag, den 24.10.2015, 22:30 +0200 schrieb MigMit:

...
At the very least, "bound at" should help IDEs (Emacs in particular) show exactly the right places.

an IDE that offers such a deep integration will hopefully not parse data meant for human consumption.

Hope is good. Reality, however, is different. At least haskell-mode in Emacs DOES parse such data, when you try to load your file in REPL.

...

IDEs should ideally make use of something based on the GHC API.

I agree. But the key word here is "ideally". Second thought though — do we really want to create a gap between error messages from the compiler and whatever IDE tells us? After all, text output from GHC is ALSO a kind of API.

...

If that is not possible, then I’d advocate a flag, say "-fverbose-error- messages" or similar that includes all detail that might be relevant for an IDE, and maybe even in a nicer-to-parse format.

Doesn't seem worth it to me. Current format is quite parseable, and not really bad for human eyes either.

Joachim Breitner

4:45 p.m.

Hi, Am Sonntag, den 25.10.2015, 21:30 +0100 schrieb MigMit:

...

Doesn't seem worth it to me. Current format is quite parseable, and not really bad for human eyes either.

I know that you meant this as a litote, but let me ignore that I know that for a moment to reply, that “not really bad” is definitely not good enough for me, and I want the compiler to print messages that are meant for my consumption to be in the _best_ possible format. Or at least try that. Obviously, there is no “best” for every human. But things get easier if we do not have to overly worry about computers as well. It goes the other way as well. IDEs would tremendously benefit if the error location would not just be a position but a whole span. But clearly (I hope) we do not want to include this information in the output that we read. BTW, does Emacs really parse _this_ bit of information? Most GHC integrations that I have seen match on the first line to indicate the file and position of the overall error, and take the error verbatim. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

MigMit

5:03 p.m.

...

On 25 Oct 2015, at 21:45, Joachim Breitner wrote:

Hi,

Am Sonntag, den 25.10.2015, 21:30 +0100 schrieb MigMit:

...
Doesn't seem worth it to me. Current format is quite parseable, and not really bad for human eyes either.

I know that you meant this as a litote,

Please, don't say "know" when you mean "assume". It's especially annoying when you assume wrong.

...

but let me ignore that I know that for a moment to reply, that “not really bad” is definitely not good enough for me, and I want the compiler to print messages that are meant for my consumption to be in the _best_ possible format. Or at least try that.

Obviously, there is no “best” for every human. But things get easier if we do not have to overly worry about computers as well.

I think that's a wrong approach. My theory is that the concepts "easy to read for a human with some experience" and "easy to parse for a computer" are two closely related notions. Sure, they aren't identical — a binary format might still be quite easy to parse, but completely unreadable for human — but they go hand in hand. Even with binary formats — if, for example, there is a clear notion of "statement" in this binary formats, and statements are separated by the byte "0xff", it's easier both for a human (equipped with binary editor) and for a computer than, for example, if the length of the statement is determined by the first byte. But! It's much easier to argue about "what's easier for a computer" than the same thing for humans.

...

BTW, does Emacs really parse _this_ bit of information? Most GHC integrations that I have seen match on the first line to indicate the file and position of the overall error, and take the error verbatim.

Last time I checked, Emacs transformed such positions into hyperlinks.

Evan Laforge

3 Nov 3 Nov

7:37 p.m.

A diff is up at https://phabricator.haskell.org/D1427 On Sat, Oct 24, 2015 at 1:14 PM, Evan Laforge wrote:

...

Ok, ticket created. I'll go see how much I can figure out on my own.

https://ghc.haskell.org/trac/ghc/ticket/11014

WRT the "bound at" bits in "relevant bindings", I have no strong opinion. What about omitting them if they are in the same file as the main error? Or maybe they always are? I'm not totally clear how it chooses which bindings are relevant.

On Sat, Oct 24, 2015 at 12:50 PM, Simon Peyton Jones wrote:

...
I’m all for it. Can advise. (Make a ticket.)

Thanks!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of Evan Laforge Sent: 24 October 2015 03:48 To: GHC users Subject: type error formatting

Here's a typical simple type error from GHC:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5) In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical. Notice the same effect in the previous sentence :) After I see a type error the next thing I want to see is the where it happened, so I have to skip over the bindings, which can be long and complicated. Then I usually know what to do, and only look into the bindings if something more complicated is going on, like wonky inference. So how about reordering the message:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

After this, why not go one step further and set off the various sections visibly to make it easier to scan. The context section can also be really long if it gets an entire do block or record:

Derive/Call/India/Pakhawaj.hs:142:62: * Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])] * In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’ * Relevant bindings include syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Or alternately, taking up a bit more vertical space:

Derive/Call/India/Pakhawaj.hs:142:62: Couldn't match type ‘Text’ with ‘(a1, Syllable)’ Expected type: [([(a1, Syllable)], [Sequence Bol])] Actual type: [([Syllable], [Sequence Bol])]

----------------------------- In the second argument of ‘mapMaybe’, namely ‘all_bols’ In the second argument of ‘($)’, namely ‘mapMaybe (match_bols syllables) all_bols’

----------------------------- Relevant bindings include

syllables :: [(a1, Syllable)] (bound at Derive/Call/India/Pakhawaj.hs:141:16) best_match :: [(a1, Syllable)] -> Maybe (Int, ([(a1, Syllable)], [(a1, Sequence Bol)])) (bound at Derive/Call/India/Pakhawaj.hs:141:5)

Thoughts? It seems simple enough that I could do myself, but of course not without buy-in.

wren romano

30 Oct 30 Oct

9:26 p.m.

On Fri, Oct 23, 2015 at 10:48 PM, Evan Laforge wrote:

...

Here's a typical simple type error from GHC:

[...]

I've been having more trouble than usual reading GHC's errors, and I finally spent some time to think about it. The problem is that this new "relevant bindings include" section gets in between the expected and actual types (I still don't like that wording but I've gotten used to it), which is the most critical part, and the location context, which is second most critical.

+1 to reordering the presentation and to adding bullets (or whatever) to better demarcate the sections. I've been bit by this a lot recently. With "normal" type errors it's quick and easy to figure out what went wrong, but especially when the issue has to do with type equality constraints, it takes far too much time to sift through the error message to find the relevant information[1]. I also wonder whether we should add in some flags for controlling how much verbosity we get from error/warning messages. Sometimes we want all the info we can get, whereas other times it'd be nice to just get the bare minimum (e.g., when we're mainly interested in a yes/no response and a line number for where things broke) [1] perhaps type equality errors should be presented differently than other type errors? The most relevant bits here are (a) what equality do we need, (b) what equalities do we have, and (c) what are the local bindings and their types (so we know where the various indices came from). Which is a bit different from the relevant information for an "expected Foo, found Bar" type error -- Live well, ~wren

3485

Age (days ago)

3496

Last active (days ago)

List overview

Download

15 comments

9 participants

participants (9)

Edward Z. Yang
Evan Laforge
Joachim Breitner
Malcolm Wallace
MigMit
Roman Cheplyaka
Ryan Trinkle
Simon Peyton Jones
wren romano