[erlang-questions] Better error messages would be helpful
Fri May 17 10:27:28 CEST 2013
While I'm absolutely buying your argument about checking brackets during lexical analysis, I'm not sure the OTP team would like that seeing how they are quite frisky with my =<< fix; wouldn't checking them there bring syntax knowledge into the lexer, something they want to avoid?
Le 17 mai 2013 à 03:08, Richard A. O'Keefe a écrit :
> 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.
More information about the erlang-questions