[erlang-questions] Better error messages would be helpful

[Richard A. O'Keefe]

On 16/05/2013, at 8:30 PM, Anthony Ramine wrote:

> Hello Richard,
> 
> To silence the undefined error, the parser would need to be able to know it indeed gave up on it; that is not so straightforward.
> 
> For the syntax error to be more useful, that also would require either heavy yecc surgery or rewritting erl_parse to be an handwritten descent-recursive parser --that is a thing I've always wanted to do.

It all depends on the structure of the compiler.
For example, I have an AWK->Java compiler written in C++ as an exercise;
it needs some work on the symbol table and the runtime needs finishing,
but then it will be open-sourced.

There are three phases, not entirely unlike Erlang.
(1) Lexical analysis builds a sequence of token records in memory.
(2) Parsing recycles those tokens into an AST, resolves variables,
    and does some very crude type inference.
(3) Code generation emits Java.

If a lexical error occurs, no parsing is done.
And brackets are checked during lexical analysis:
the lexical analyser only needs to keep a simple stack
of what brackets are open.

My crude Erlang pretty-printer plays the same check-brackets-during-
lexical-analysis-with-a-straightforward-stack trick.

In the days when compiling meant submitting a deck of punched cards in the
morning and getting a listing in the late afternoon, it was important for
a compiler to check as much as it could.

These days, it is more important that a compiler's messages should not be
misleading, and parse errors following lexical errors (including bracket
errors as lexical errors) are generally pretty misleading.

> Otherwise we can still improve the situation quite a lot with just column numbers, when they get merged someday.

In this specific case, it would not have helped.  It was perfectly clear
exactly where the parser ran into trouble.  It just wasn't clear _why_ it
ran into trouble.

Part of the problem is precisely the fact that the parser is written in Yecc.