Separating typechecking and type error reporting in two passes?

[Nicola Gigante]

> Il giorno 29 nov 2016, alle ore 17:52, Joachim Breitner <mail at joachim-breitner.de> ha scritto:
> 
> Hi,
> 
> I guess the claim is still true: Think about just the amount of code
> you compile when you install your dependencies.
> 
> But you are right that when the programmer sits there and waits for a
> result, that’s when snappyness is important. I don’t expect this change
> to be human-noticable in terms of performance, and the prospect of
> getting more useful error messages (which are easier to grasp and fix)
> will certainly outweigh that.
> 
> Anyways, performance aspects are just a side-effect of this.
> 

Hi all,

the following is a comment from an interested outsider. I’ve never
hacked on GHC, but I have some little experience with clang internals.

Compiling C++ code is a very heavy task, especially when a lot of templates
are involved, and the design of the whole compiler is particularly 
performance-driven. As you may know, they nevertheless put a lot of effort
on the understandability of compilation errors. As a coding guideline, they
treat the compilation of correct code as the “fast path”, and the error reporting
as the slow path. This doesn’t mean the compiler is slow at reporting errors:
as much as you can go around the AST to collect information, 
you won’t ever be able to slow it so much as to outweigh the time to codegen
the code if it were correct. So at the end, the programmer experiences a fast iteration 
anyway. All of this to say that my humble experience with clang suggests that an improvement 
in error messages is worth a little slow down in the incorrect code compilation path,
and it is a very important goal to pursue even if it had to slow down some micro benchmark.

Greetings,
Nicola