[antlr-interest] NoViableAltException in ()? rule

[Ingo Maier]

On Thu, 2004-12-02 at 12:52, Terence Parr wrote:
> On Dec 2, 2004, at 2:35 PM, Ingo Maier wrote:
> 
> >
> > Hi,
> >
> > for a (x)? the generated code seems not only to check if an x comes
> > next, but also what can come after (or instead of) that x. If such a
> >
> 
> Yes, because it tries to find errors as soon as possible.

Well, I don't get the point. Is it finding it earlier? E.g. when
tryBlock() below gets called in some other rules context, then the
following method will complain. Does it matter if the end of tryBlock()
or the beginning of the following method complain? 

> 
> > token doesn't follow it throws a NoViableAltException.
> >
> > For example in the java grammar:
> >
> > tryBlock: "try"^ compoundStatement (handler)* (finallyClause)?;
> >
> > If no finally clause comes next, it also checks for possibly following
> > tokens in the generated typeBlock() method:
> >
> > switch ( LA(1)) {
> >   case LITERAL_finally:
> >   {
> >     ...
> >   }
> >   case FINAL:
> >   case ABSTRACT:
> >    ...
> >      break;
> >
> >
> > Why? Those following tokens have nothing to do with the rule tryBlock
> > itself, but only with the enclosing grammar, right?
> 
> Yes, but it is fine to check that lookahead, right?
> 
> > As a consequence java snippets followed by some non-java text cannot be
> > parsed without an exception:
> >
> > try { /*...*/ } catch(Exception e) { /*...*/ } /* no finally clause */
> > here comes some text...
> >
> > When I call tryBlock(), "here" is not expected because of the generated
> > switch block as pasted above. However, "here" should have nothing to do
> > with the tryBlock() rule.
> 
> Well, you get an error because that text is not part of the grammar and 
> ANTLR wants you to know. ;)
> 
> You are actually asking a different question, which is "how do I handle 
> island grammars in ANTLR?"  Meaning that you want ANTLR to only match a 
> part of the text.  

Yes, that is my intention. But my question above remains... :)

> Given input:
> 
> > try { /*...*/ } catch(Exception e) { /*...*/ } /* no finally clause */
> > here comes some text...
> 
> I think you'll be hard pressed even by hand to figure out when Java is 
> not coming next.  For example, here's a valid definition:
> 
> here comes;
> 
> depending on the type definitions.  You need a sentinel like JSP has or 
> other island grammars to indicate what is what.

Yes, I am totally aware of that. We are quite restrictive what part of a
grammar may be embedded and where. E.g. wrapping Java statements into [
and ] should be (relatively) save. However, a try/catch without a
finally block wrapped into [ ] will throw an Exception at ]. Maybe we
can fiddle it out in some way whether it was an exception because of a
malformed Java statement or because of a "()?" construct. But that would
be no fun :) and currently I don't really see how.

Regards,
Ingo



 
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/