Loading ...
Sorry, an error occurred while loading the content.
 

Re: [antlr-interest] NoViableAltException in ()? rule

Expand Messages
  • Terence Parr
    ... Yes, because it tries to find errors as soon as possible. ... Yes, but it is fine to check that lookahead, right? ... Well, you get an error because that
    Message 1 of 5 , Dec 2, 2004
      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.

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

      :)

      Ter
      --
      CS Professor & Grad Director, University of San Francisco
      Creator, ANTLR Parser Generator, http://www.antlr.org
      Cofounder, http://www.jguru.com
      Cofounder, http://www.knowspam.net enjoy email again!
    • Ingo Maier
      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 token doesn t
      Message 2 of 5 , Dec 2, 2004
        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
        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?

        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.

        Thanks in advance,
        Ingo
      • Ingo Maier
        ... 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
        Message 3 of 5 , Dec 2, 2004
          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
        Your message has been successfully submitted and would be delivered to recipients shortly.