On Fri, Oct 23, 2015 at 10:48 PM, Evan Laforge
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