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

Re: [antlr-interest] Non-determinism (again :-(

Expand Messages
  • Robert Colquhoun
    Hello, ... The above is a bit weird, how will it know when the statement_line rule ends and a new statement_line rule should be attempted to be matched in
    Message 1 of 5 , Apr 4, 2003
    • 0 Attachment
      Hello,

      At 04:19 PM 3/04/2003 +0100, Anthony Youngman wrote:
      >You can see I've tried to force statement_list into a node on its own ...
      >
      >and my treeparser rules ...
      >
      >loopst
      > : #("LOOP" {System.out.println("LABL LP1");} statement_list
      > "REPEAT" {System.out.println("GOTO LP1");} )
      > ;
      >
      >statement_line : ( ( statement)+ ) ;
      >
      >statement_list : ( (statement_line )+ ) ;

      The above is a bit weird, how will it know when the 'statement_line' rule
      ends and a new 'statement_line' rule should be attempted to be matched in
      the 'statement_list' rule?

      Either statement_line should be made into a tree rather than list of
      statements or the statement_list rule should just consist of '(statement)+'.

      PS Yesterday you mentioned that at the end of all this, you would write up
      an example grammar....have you looked in the examples directory there is a
      'tinybasic' grammar which looks very similar to what you appear to be
      proposing.

      - Robert
    • Anthony Youngman
      Thanks Rob. It s got rid of the non-determism. And thanks for the heads-up to tinybasic - I had been trying to make statement_line and/or statement_tree into
      Message 2 of 5 , Apr 4, 2003
      • 0 Attachment
        RE: [antlr-interest] Non-determinism (again :-(

        Thanks Rob. It's got rid of the non-determism. And thanks for the heads-up to tinybasic - I had been trying to make statement_line and/or statement_tree into an AST node (I had suspected the problem was they were both degenerate trees or plain lists :-) but I just couldn't get it to Tool or compile - I'd got the node generation syntax wrong I think. And the comments in it will help. It should be touted rather more, as I don't think people are that likely to stumble across it.

        NOTE TO TER! In "XML parsing the easy way", you mention that "there is a one-2-one correspondence between Parser and TreeWalker rules". This is a counter-example! The problem is that both SEMI and EOL are end-of-statement markers, but they can (sometimes, not always) modify the preceding control structure as well.

        Cheers,
        Wol

        -----Original Message-----
        From: Robert Colquhoun [mailto:rjc@...]
        Sent: 04 April 2003 10:46
        To: 'antlr-interest@yahoogroups.com'
        Subject: Re: [antlr-interest] Non-determinism (again :-(


        Hello,

        At 04:19 PM 3/04/2003 +0100, Anthony Youngman wrote:
        >You can see I've tried to force statement_list into a node on its own ...
        >
        >and my treeparser rules ...
        >
        >loopst
        >         : #("LOOP" {System.out.println("LABL LP1");} statement_list
        > "REPEAT" {System.out.println("GOTO LP1");} )
        >         ;
        >
        >statement_line : ( ( statement)+ ) ;
        >
        >statement_list : ( (statement_line )+ ) ;

        The above is a bit weird, how will it know when the 'statement_line' rule
        ends and a new 'statement_line' rule should be attempted to be matched in
        the 'statement_list' rule?

        Either statement_line should be made into a tree rather than list of
        statements or the statement_list rule should just consist of '(statement)+'.

        PS Yesterday you mentioned that at the end of all this, you would write up
        an example grammar....have you looked in the examples directory there is a
        'tinybasic' grammar which looks very similar to what you appear to be
        proposing.

          - Robert



         

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



        This transmission is intended for the named recipient only. It may contain private and confidential information. If this has come to you in error you must not act on anything disclosed in it, nor must you copy it, modify it, disseminate it in any way, or show it to anyone. Please e-mail the sender to inform us of the transmission error or telephone ECA International immediately and delete the e-mail from your information system.

        Telephone numbers for ECA International offices are: Sydney +61 (0)2 9911 7799, Hong Kong + 852 2121 2388, London +44 (0)20 7351 5000 and New York +1 212 582 2333.

      • mzukowski@yci.com
        ... end-of-statement ... structure as ... Can you show some examples? Both rules and example code to parse. Monty
        Message 3 of 5 , Apr 4, 2003
        • 0 Attachment
          > This is a counter-example! The problem is that both SEMI and EOL are
          end-of-statement
          > markers, but they can (sometimes, not always) modify the preceding control
          structure as
          > well.

          Can you show some examples? Both rules and example code to parse.

          Monty
        • Anthony W Youngman
          Okay. Let s take if then else syntax. The assorted variants can be IF A EQ B THEN C = 3 D = 4 END ELSE E = 5 F = 6 END or IF A EQ B THEN C = 3; D = 4 ELSE E
          Message 4 of 5 , Apr 7, 2003
          • 0 Attachment
            Okay. Let's take "if then else" syntax. The assorted variants can be

            IF A EQ B THEN
            C = 3
            D = 4
            END ELSE
            E = 5
            F = 6
            END

            or

            IF A EQ B THEN C = 3; D = 4 ELSE E = 5; F = 6
            or

            IF A EQ B
            THEN C = 3; D = 4
            ELSE E = 5; F = 6

            (or other assorted variants...)

            This then goes through my parser rules (note that I haven't got round to
            sorting out assigns as in my example, but the grammar won't "Tool"
            without the warnings...)

            statement : ( inputst | printst | exitst | ifst | loopst | "NULL" ) ;
            statement_line : (statement ( SEMI! statement)* ) ;
            statement_list : ( (statement_line (EOL!)+ )+ ) ;

            If you look at the output from that, both statement_line and
            statement_list just give you a degenerate tree consisting of a list of
            statements. That's why my treeparser was presumably blowing up. If you
            look back to my original post, the treeparser rules were

            statement_line : ( ( statement)+ ) ;
            statement_list : ( (statement_line )+ ) ;

            Which blew up with the non-determinism warning...Rob's post gave me the
            hint I needed - eliminate one of the treeparser rules and the warning
            goes away. Now that I'm working on creating a virtual root for
            statement_list, that's an alternative way of making the non-determinism
            go away (and may prove to be the only route to a working grammar), but
            my example above is certainly an exception to "one parser rule to one
            treeparser rule" - the parser was doing exactly what I expected/wanted
            and the treeparser was ambiguous.

            Cheers,
            Wol

            -----Original Message-----
            From: mzukowski@... [mailto:mzukowski@...]
            Sent: 04 April 2003 17:31
            To: antlr-interest@yahoogroups.com
            Subject: RE: [antlr-interest] Non-determinism (again :-(


            > This is a counter-example! The problem is that both SEMI and EOL are
            end-of-statement
            > markers, but they can (sometimes, not always) modify the preceding
            control
            structure as
            > well.

            Can you show some examples? Both rules and example code to parse.

            Monty



            Your use of Yahoo! Groups is subject to
            http://docs.yahoo.com/info/terms/
          Your message has been successfully submitted and would be delivered to recipients shortly.