Re: type error formatting

[Evan Laforge]

A diff is up at https://phabricator.haskell.org/D1427

On Sat, Oct 24, 2015 at 1:14 PM, Evan Laforge <qdun...@gmail.com> 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 <simo...@microsoft.com>
> wrote:
>>
>> I’m all for it.   Can advise.  (Make a ticket.)
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Simon
>>
>>
>>
>> From: Glasgow-haskell-users
>> [mailto:glasgow-haskell-users-boun...@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])]
>>

Re: type error formatting

[wren romano]

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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[Joachim Breitner]

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
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[MigMit]

> 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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[Joachim Breitner]

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
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[MigMit]

> 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.

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

Re: type error formatting

[Ryan Trinkle]

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
>
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

RE: type error formatting

[Simon Peyton Jones]

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

Thanks!

Simon

From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@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

Re: type error formatting

[MigMit]

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 <qdun...@gmail.com> 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 <simo...@microsoft.com> 
> wrote:
> I’m all for it.   Can advise.  (Make a ticket.)
> 
>  
> 
> Thanks!
> 
>  
> 
> Simon
> 
>  
> 
> From: Glasgow-haskell-users 
> [mailto:glasgow-haskell-users-boun...@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)]
&g

Re: type error formatting

[Evan Laforge]

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 <simo...@microsoft.com>
wrote:

> I’m all for it.   Can advise.  (Make a ticket.)
>
>
>
> Thanks!
>
>
>
> Simon
>
>
>
> *From:* Glasgow-haskell-users [mailto:
> glasgow-haskell-users-boun...@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

Re: type error formatting

[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.

Regards,
Malcolm

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

Re: type error formatting

[Joachim Breitner]

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
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[Joachim Breitner]

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
  m...@joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nome...@joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org



signature.asc
Description: This is a digitally signed message part
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[Roman Cheplyaka]

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.




signature.asc
Description: OpenPGP digital signature
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: type error formatting

[Edward Z. Yang]

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])]
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

type error formatting

[Evan Laforge]

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