type error formatting

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

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: type error formatting

Joachim Breitner-2
In reply to this post by Evan Laforge
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
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

Re: type error formatting

Malcolm Wallace-2

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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: type error formatting

Joachim Breitner-2
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
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

Re: type error formatting

Roman Cheplyaka-2
In reply to this post by Evan Laforge
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

Re: type error formatting

Ryan Trinkle-3
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users



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

RE: type error formatting

Simon Peyton Jones
In reply to this post by Evan Laforge

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

 

Thanks!

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

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

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

 

Thanks!

 

Simon

 

From: Glasgow-haskell-users [mailto:[hidden email]] 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: type error formatting

migmit-2
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 <[hidden email]> 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 <[hidden email]> wrote:
> I’m all for it.   Can advise.  (Make a ticket.)
>
>  
>
> Thanks!
>
>  
>
> Simon
>
>  
>
> From: Glasgow-haskell-users [mailto:[hidden email]] 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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

Re: type error formatting

Joachim Breitner-2
In reply to this post by Evan Laforge
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
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

Re: type error formatting

migmit-2

> On 25 Oct 2015, at 21:21, Joachim Breitner <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: type error formatting

Joachim Breitner-2
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
  [hidden email]http://www.joachim-breitner.de/
  Jabber: [hidden email]  • GPG-Key: 0xF0FBF51F
  Debian Developer: [hidden email]


_______________________________________________
Glasgow-haskell-users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

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

Re: type error formatting

migmit-2

> On 25 Oct 2015, at 21:45, Joachim Breitner <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: type error formatting

wren romano-2
In reply to this post by Evan Laforge
On Fri, Oct 23, 2015 at 10:48 PM, Evan Laforge <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Reply | Threaded
Open this post in threaded view
|

Re: type error formatting

Evan Laforge
In reply to this post by Evan Laforge
A diff is up at https://phabricator.haskell.org/D1427

On Sat, Oct 24, 2015 at 1:14 PM, Evan Laforge <[hidden email]> 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 <[hidden email]>
> wrote:
>>
>> I’m all for it.   Can advise.  (Make a ticket.)
>>
>>
>>
>> Thanks!
>>
>>
>>
>> Simon
>>
>>
>>
>> From: Glasgow-haskell-users
>> [mailto:[hidden email]] 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users