Hacker News Reader

>> Built-in line and column tracking. Any movement across a newline updates the line number, including a backwards seek. getLine and getColumn are always available and both are one-based, which makes decent error messages nearly free.

> That doesn't sound like much, but having hand-written plenty of recursive descent parsers, it's most of what you need for good error messages.

In my experience having access to the appropriate place where the parser failed is necessary but wholly insufficient for good diagnostics.

What I normally do is: only storing the byte position during the parsing itself, and then extracting the line + column when/if displaying an error.

This allows the error report mechanism to be decoupled, and the hot path of the parser has a bit less code to manage.

I don't really agree. Many top-down parsers find an error at an unexpected token. That token is often not the error. Quite often something is missing at that point, or there has been a mistake some way back. Translating e.g. "unexpected semicolon" into "keyword 'if' should be the identifier 'f'" is not easy.

I think it becomes easier if you have some oracle, like a compiler, available to check whether the end result (after introducing suggestions) is viable.

I say it like this because to me the only valid way to come to the latter class of error messages (containing constructive suggestions) is by first coming up with possible edits and then checking whether they make the whole parse and compile.