[antlr-interest] Re: strong error recovery
monty at codetransform.com
Thu Jul 29 10:04:51 PDT 2004
Here's the idea. Follow my discussion in my article about how to write
a parser which grabs tokens from the input stream and then only parses
when it sees an interesting token. In my example GOTO was one such
token that should be parsed. In your example it will be anything that
can be an expression.
The following paragraph from my article explains what I had to do about
the follow set expecting EOF.
It also happened that calling labelReferences directly from
jumpStatements didn't work because the parser assumed that EOF would
follow when in fact this was working more like a lexer which gets
called multiple times on the same stream and shouldn't be assuming EOF.
So I modified it to call labelReferences as a method, not as a rule
call, to avoid the associated lookahead. Then I also noticed I needed
to handle the case where EOLs followed the jump, so I do my own testing
of LA(1) to decide what to do. To handle syntax errors properly I also
added the expectingLabel variable and set it to false if something goes
wrong. Finally, here's the complete working BASICLabelReference.g
Now that I think about it, there are probably other ways to handle
this. For instance if you aren't passing on to a TokenStream, you
could get by with a parser rule like this:
top: (expr | .)*;
That should work for the calc.g example too (if the main rule in calc.g
is called expr)
On Jul 29, 2004, at 2:01 AM, Neurosurg wrote:
> --- In antlr-interest at yahoogroups.com, Monty Zukowski <monty at c...>
>> Take a look at my parser filter example,
>> http://www.codetransform.com/filterexample.html. It requires a bit of
>> work and understanding of ANTLR, explained in the article, but it lets
>> you use a parser to pick out certain constructs and ignore everything
> I saw your article before writing this post, it didn't helped me.
> You pursued a different goal:
> I was trying out some "extreme programming" while rewriting a parser
> for AREV Basic, exploring incremental fixes to the problem of keywords
> being used as identifiers. The first one I encountered was labels (as
> in GOTO) with the name "Exit", which is also a Basic statement. In
> this case I reasoned that I could detect the "GOTO" and then safely
> assume that what followed it was a really a label and not a keyword.
> I mean, your problem is another special case. I don't know
> maybe some ideas might be reused from your example, but it is not
> clear to me.
> Could we take calc.g from directory "examples" as a guinea
> pig and change it?
> My real grammar and its furmulae are anyway
> more complicated then calc.g, but if we could do this
> for calc.g a lot of ppl could benefit from this show case
> and use it as "antlr design pattern".
> thank you
> Yahoo! Groups Links
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
antlr-interest-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the antlr-interest