Elm has a interesting take on this: a collection of all error messages ( https://github.com/elm-lang/error-message-catalog).
I created an empty repo ( https://github.com/bollu/hask-error-messages-catalog) and shot an email to haskell-cafe asking for examples where GHC generates unintuitive error messages. Hopefully, I can start collecting these so there's context the next time this comes up. (PRs welcome :) Thanks, ~Siddharth On Mon 5 Jun, 2017, 22:56 Evan Laforge, <qdun...@gmail.com> wrote: > 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 <r...@cs.brynmawr.edu> > wrote: > > > >> On Jun 3, 2017, at 11:50 AM, Ben Gamari <b...@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@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- Sending this from my phone, please excuse any typos!
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs