John O'Donnell wrote:
[snip]
> Please, do *not* put error correction into ghc! I think error correction
> is one of the Classic Bad Ideas for a compiler. It's much better to
> focus on providing understandable error messages: when the user knows
> what the compiler thinks is wrong, it's usually not so hard to fix the
> error.
I wouldn't rate the current parser's error messages high for understandability
either.
> One error message at a time is sensible, too. Once I've fixed the first
> error, I don't want to waste time studying further error messages on the
> dubious assumption that they are unconnected to the first one. Let the
> computer do the grind work!
Sorry, but I write code differently. Generally I code a whole module
without testing it at all and then put it through the compiler. With a
sensible compiler I expect to fix about 2/3 of the errors each time I put
it through the compiler, meaning I need O(log N) passes (or parses) to fix
all the errors. With GHC I need O(N) passes. Actually a well-written and
tested parser should not normally produce cascades of error messages
when the user misses out a semicolon. I will go out on a limb and
say that MLj's parser, which I wrote and which you can download, does not.
> I would hate it if a program that I'm trying to prove theorems about
> behaves strangely, because, in the face of an error, the compiler took
> a wild guess about what was intended and produced a program that I
> never wrote.
I certainly don't think a compiler should ever compile code when it has
detected an error in the input. I would be quite happy if it didn't even
typecheck it.
