Separating typechecking and type error reporting in two passes?
monkleyon at googlemail.com
Wed Nov 30 11:59:25 UTC 2016
> But you are right that when the programmer sits there and waits for a
> result, that’s when snappyness is important.
I had a random idea based on this observation:
(With a certain flag set) the compiler could follow the existing
strategy until it has hit the first n errors, possibly with n=1. Then it
could switch off the context overhead and all subsequent errors could be
deferred or not fleshed out. Or, alternatively, the proposed new
strategy is used, but the second pass only looks at the first n errors.
Benefit: Correct code is on the fast path, but error reporting doesn't
add too much of an overhead. My experience when using the compiler to
have a conversation about errors was that I was correcting one or two
errors at a time, then re-compiling. I discarded all the extra
information about the other errors anyway, at least most of the time. I
don't know if that is a usual pattern, but if it is we might as well
This idea could already benefit from a separation, but we can go further.
What if, in interactive sessions, you would only get the result of the
first pass at first. No details, but only a list of error positions. In
some cases, that is all you need to find a dumb typo. It also doesn't
clutter the screen with loads of fluff while still giving you a basic
idea of how much is wrong. Now what if you could then instruct the
system to do the second pass at places you choose, interactively? In
other words the conversation would be even more conversational.
Of course the benefits are debatable and this is not something that's
going to be happening soon anyway. But for me the idea alone is an
argument for the proposed new separation, because it would give us the
flexibility to think of features like this.
More information about the ghc-devs