Interested to help with error messages

[Evan Laforge]

This is a bit off topic, but is there a collection of not-so-great
error messages along with opinions about what they should be?  Like a
wiki page or something?

I just stumbled across one and was going to complain, but didn't know
the most productive way to do that, aside from try to fix it myself.

Specifically, I'm working in a small EDSL that uses lots of small
expressions composed together with a repurposed (.) operator.  The
pretty printer layout causes the context section of each type error to
become huge, for instance:

Derive/Solkattu/MridangamScore.hs:110:60:
    Couldn't match type ‘Derive.Solkattu.Sequence.Note
                           (Derive.Solkattu.Solkattu.Note
                              Derive.Solkattu.MridangamDsl.Stroke)’
                   with ‘[Derive.Solkattu.Sequence.Note
                            (Derive.Solkattu.Solkattu.Note
                               Derive.Solkattu.MridangamDsl.Stroke)]’
    Expected type: [Sequence]
      Actual type: [Derive.Solkattu.Sequence.Note
                      (Derive.Solkattu.Solkattu.Note
                         Derive.Solkattu.MridangamDsl.Stroke)]
    In the second argument of ‘($)’, namely
      ‘nadai 7
       $ repeat 2 kook
         . od
           . __
             . k
               . d
                 . __
                   . k
         [ keeps walking to the right for many many lines ]
    In the second argument of ‘($)’, namely
      ‘korvai adi
       $ nadai 7
         $ repeat 2 kook
           . od
             [ again ]
    In the second argument of ‘($)’, namely
       [ and again ]


You can probably easily reproduce this by making a lot of little
expressions and putting an error in someplace.  What I think it should
be is put more things on a horizontal line, or maybe cap the
expression at a certain number of lines.  Or maybe the "zooming out"
contexts could replace the previous expression with {- previous
expression -} to emphasize the difference.


Also, the other thing to think about before changing type errors is
that tons of ghc tests rely on (almost) exact error output.  Probably
the first task is to make an abstract output, then change the tests to
rely on that (or at least a legacy formatting mode), so that every
change doesn't break a million tests.

On Sun, Jun 4, 2017 at 8:20 PM, Richard Eisenberg <rae at cs.brynmawr.edu> wrote:
>
>> On Jun 3, 2017, at 11:50 AM, Ben Gamari <ben at smart-cactus.org> wrote:
>>
>> In particular, Richard Eisenberg
>> advocated that error message documents look like,
>>
>>    -- A dynamically typed value embedded in an error message
>>    data ErrItem = forall a. (Outputable a, Typeable a). ErrItem a
>>
>>    type ErrDoc = Doc ErrItem
>
> I retract this argument.
>
> Otherwise, I contribute only a hearty thanks to whoever is working on this, which likely has a larger impact on the adoption of Haskell than anything I've done. :)
>
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs