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