<br><br><div class="gmail_quote">On Fri, May 17, 2013 at 3:08 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 16/05/2013, at 8:30 PM, Anthony Ramine wrote:<br>
<br>
> Hello Richard,<br>
><br>
> 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.<br>
><br>
> 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.<br>
<br>
</div>It all depends on the structure of the compiler.<br>
For example, I have an AWK->Java compiler written in C++ as an exercise;<br>
it needs some work on the symbol table and the runtime needs finishing,<br>
but then it will be open-sourced.<br>
<br>
There are three phases, not entirely unlike Erlang.<br>
(1) Lexical analysis builds a sequence of token records in memory.<br>
(2) Parsing recycles those tokens into an AST, resolves variables,<br>
    and does some very crude type inference.<br>
(3) Code generation emits Java.<br>
<br>
If a lexical error occurs, no parsing is done.<br>
And brackets are checked during lexical analysis:<br>
the lexical analyser only needs to keep a simple stack<br>
of what brackets are open.<br></blockquote><div><br>That's a nice idea - we could easily stick an extra pass between <br>scanning and parsing to do this <br><br>/Joe<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
My crude Erlang pretty-printer plays the same check-brackets-during-<br>
lexical-analysis-with-a-straightforward-stack trick.<br>
<br>
In the days when compiling meant submitting a deck of punched cards in the<br>
morning and getting a listing in the late afternoon, it was important for<br>
a compiler to check as much as it could.<br>
<br>
These days, it is more important that a compiler's messages should not be<br>
misleading, and parse errors following lexical errors (including bracket<br>
errors as lexical errors) are generally pretty misleading.<br>
<div class="im"><br>
> Otherwise we can still improve the situation quite a lot with just column numbers, when they get merged someday.<br>
<br>
</div>In this specific case, it would not have helped.  It was perfectly clear<br>
exactly where the parser ran into trouble.  It just wasn't clear _why_ it<br>
ran into trouble.<br>
<br>
Part of the problem is precisely the fact that the parser is written in Yecc.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>