5 ms·

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 g

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.

alipang 6y ago
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.
red2awn 6y ago
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 6y ago
  Maybe you should check out the Menhir parser generator instead. Some links: http://gallium.inria.fr/~fpottier/menhir/manual.pdf http://gallium.inria.fr/~fpottier/menhir/manual.pdf https://semantic-domain.blogspot.com/2015/11/error-handling-in-menhir.html https://semantic-domain.blogspot.com/2015/11/error-handling-... https://baturin.org/blog/declarative-parse-error-reporting-with-menhir/ https://baturin.org/blog/declarative-parse-error-reporting-w...
- mhh__ 6y ago
  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)