type error formatting

[wren romano]

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