[antlr-interest] Re: strong error recovery

[Monty Zukowski]

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

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)

Monty

On Jul 29, 2004, at 2:01 AM, Neurosurg wrote:

> --- In antlr-interest at yahoogroups.com, Monty Zukowski <monty at c...> 
> wrote:
>> 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
>> else.
>
> I saw your article before writing this post, it didn't helped me.
>
> You pursued a different goal:
>
> [quote]
> 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.
> [/quote]
>
> 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
> --
> Valery
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>



 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/