[benschulz]

I'm not sure I buy the premise. The point of the original article was that you shouldn't dig a hole for yourself to get out of later. Compiler writers usually go out of their way, digging extra deep holes, to accept a broad range of invalid input. Not because they like complexity---though, as a group they.. I digress---but because it lets them give more valuable user feedback.

[red2awn]

Yeah I am currently writing a compiler, turns out for useful error messages my parser should accept a superset of my language, then validate it afterwards.

[nsajko]

Maybe you should check out the Menhir parser generator instead.

Some links:

http://gallium.inria.fr/~fpottier/menhir/manual.pdf

https://semantic-domain.blogspot.com/2015/11/error-handling-...

https://baturin.org/blog/declarative-parse-error-reporting-w...

[mhh__]

The way the D compiler does it is by parsing until it finds an error, marking the node as "poisoned" then walking back up until it can keep going.

It seems to work although I would include a "fail early" flag just to help with enormous error messages (if you apply the principle to sema as well)

[alipang]

Yeah, the main coherent point I take out of this is that it makes sense to provide capabilities rather than to check them, i.e. if you have access to a certain API then you're by construction allowed to use it. It seems this is something the author has been working on.

This is then somehow shoehorned into "Parse / Don't typecheck" but it doesn't make much sense honestly.