[erlang-questions] Better error messages would be helpful

[Anthony Ramine]

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?

Regards,

-- 
Anthony Ramine

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