[erlang-questions] Better error messages would be helpful

Joe Armstrong erlang@REDACTED
Fri May 17 12:02:30 CEST 2013

On Fri, May 17, 2013 at 3:08 AM, Richard A. O'Keefe <ok@REDACTED>wrote:

> 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.

That's a nice idea - we could easily stick an extra pass between
scanning and parsing to do this


> 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.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130517/1bedbe6f/attachment.htm>

More information about the erlang-questions mailing list