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

Re: [antlr-interest] on parsers look and feel + #["="]

Expand Messages
  • Ric Klaren
    ... Do you have lexer and parser in one file ? I have them in separate files and get no warnings. Cheers, Ric -- ... Evil will always triumph, because Good is
    Message 1 of 12 , Dec 1, 2003
      On Fri, Nov 28, 2003 at 06:22:14PM +0200, Cristian Amitroaie wrote:
      > With these (already mentioned somewhre in this thread) warnings:
      >
      > LookLexer.g:14:8: warning:Redefinition of token in tokens {...}: EQ
      > LookLexer.g:15:10: warning:Redefinition of token in tokens {...}: SEMI

      Do you have lexer and parser in one file ? I have them in separate files
      and get no warnings.

      Cheers,

      Ric
      --
      -----+++++*****************************************************+++++++++-------
      ---- Ric Klaren ----- j.klaren@... ----- +31 53 4893722 ----
      -----+++++*****************************************************+++++++++-------
      "Evil will always triumph, because Good is dumb." --- Spaceballs
    • Ric Klaren
      Hi, ... Doing this in the tree construction stuff is probably not a good idea. There s no unique mapping from AST type (e.g. as returned by getType() (first
      Message 2 of 12 , Dec 1, 2003
        Hi,

        On Fri, Nov 28, 2003 at 05:57:39PM +0200, Cristian Amitroaie wrote:
        > We still have an issue, that is #[] constructs when building ASTs. It's not
        > straightforward. You need to write #[EQ, "="]. Why not #["="]? Afterall
        > antlr computes a token table with enum_type/string/numbers associations...
        >
        > Maybe we should ask Terr for an enhancement?

        Doing this in the tree construction stuff is probably not a good idea.
        There's no unique mapping from AST type (e.g. as returned by getType()
        (first parameter of #[x,y]) and the text (as returned by getText(), 2nd
        parameter). So this can easily blow up. (As Thomas Brandon already pointed
        out if I recall right)

        Another reason against it is the crummy action parser interface in antlr
        I'd rather not see this added on top of that (at least I won't touch it
        with a 100ft pole after that happens unless its completely rewritten :)
        that piece of code is enough of a horror already :(

        Cheers,

        Ric
        --
        -----+++++*****************************************************+++++++++-------
        ---- Ric Klaren ----- j.klaren@... ----- +31 53 4893722 ----
        -----+++++*****************************************************+++++++++-------
        "I think we better split up."
        "Good idea. We can do more damage that way."
        --- Ghostbusters
      • Cristian Amitroaie
        ... It could warn if not unique... ... OK, than maybe a future enhancement (maniac :)? Yet, if you feel it can easily break, I ll take your word for that (hope
        Message 3 of 12 , Dec 1, 2003
          On Monday 01 December 2003 15:18, Ric Klaren wrote:
          > Hi,
          >
          > On Fri, Nov 28, 2003 at 05:57:39PM +0200, Cristian Amitroaie wrote:
          > > We still have an issue, that is #[] constructs when building ASTs. It's
          > > not straightforward. You need to write #[EQ, "="]. Why not #["="]?
          > > Afterall antlr computes a token table with enum_type/string/numbers
          > > associations...
          > >
          > > Maybe we should ask Terr for an enhancement?
          >
          > Doing this in the tree construction stuff is probably not a good idea.
          > There's no unique mapping from AST type (e.g. as returned by getType()
          > (first parameter of #[x,y]) and the text (as returned by getText(), 2nd
          > parameter). So this can easily blow up. (As Thomas Brandon already pointed
          > out if I recall right)

          It could warn if not unique...

          >
          > Another reason against it is the crummy action parser interface in antlr
          > I'd rather not see this added on top of that (at least I won't touch it
          > with a 100ft pole after that happens unless its completely rewritten :)
          > that piece of code is enough of a horror already :(

          OK, than maybe a future enhancement (maniac :)?

          Yet, if you feel it can easily break, I'll take your word for that (hope as
          time goes I'll get it ;).

          Thanks a lot,
          Cristian

          >
          > Cheers,
          >
          > Ric
        • Cristian Amitroaie
          Hi Ric, ... 2 files, lexer imports parser s vocab (a lot of keywords, not that I like it). I attached a small example. ... [cristian@lapc Look]$ java
          Message 4 of 12 , Dec 1, 2003
            Hi Ric,

            > >
            > > LookLexer.g:14:8: warning:Redefinition of token in tokens {...}: EQ
            > > LookLexer.g:15:10: warning:Redefinition of token in tokens {...}: SEMI
            >
            > Do you have lexer and parser in one file ? I have them in separate files
            > and get no warnings.

            2 files, lexer imports parser's vocab (a lot of keywords, not that I like it).

            I attached a small example.

            ---
            [cristian@lapc Look]$ java antlr.Tool LookParser.g
            ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
            [cristian@lapc Look]$ java antlr.Tool LookLexer.g
            ANTLR Parser Generator Version 2.7.2 1989-2003 jGuru.com
            LookLexer.g:14:8: warning:Redefinition of token in tokens {...}: EQ
            LookLexer.g:15:10: warning:Redefinition of token in tokens {...}: SEMI
            ---

            10x,
            Cristian
          Your message has been successfully submitted and would be delivered to recipients shortly.