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

Re: submitted AST factory changes to repository

Expand Messages
  • Ric Klaren
    Hi, ... A bit late in speaking up about this.. but is this really something you want to do/support? It allows a user to invalidate the mapping of a type number
    Message 1 of 3 , Dec 2, 2002
    • 0 Attachment
      Hi,

      On Fri, Nov 29, 2002 at 03:40:06PM -0800, Terence Parr wrote:
      > > 1. #[FOO] always builds an AST node of the default type because
      > > the ASTFactory only knows about the default. In future if you say
      > >
      > > tokens {
      > > PLUS<AST=PLUSNode>;
      > > ...
      > > }
      > > then I'll make action #[PLUS] create the right node. You can also
      > > say
      > > #[ID,"foo","VarNode"] (3rd arg is the type of node to create).
      >
      > I have modified action.g to handle the 3rd arg.

      A bit late in speaking up about this.. but is this really something you
      want to do/support? It allows a user to invalidate the mapping of a type
      number to a instance of a certain AST node class. It sounds a bit like
      providing a user with quite some rope.. or a nice new shiny handgun to hit
      his/her foot :)

      If a user makes some code to do stuff on an AST which checks the type
      numbers and not the exact class type he may get weird results if you
      support this. I'd at least tag it with a big 'know-what-your-are-doing' tag
      in the documentation.

      I cannot really think of a case where you'd even want to do this... But as
      usual feel free to correct me =)

      Cheers,

      Ric
      --
      -----+++++*****************************************************+++++++++-------
      ---- Ric Klaren ----- klaren@... ----- +31 53 4893722 ----
      -----+++++*****************************************************+++++++++-------
      "You know how to use that thing?" [pointing to the sword]
      "Sure.. The pointy end goes into the other guy."
      --- The Mask of Zorro
    • Ric Klaren
      Hi, ... I don t see your last point actually. I m all in favour of abstracting the AST construction/manipulation away from the target language. But the thing
      Message 2 of 3 , Dec 5, 2002
      • 0 Attachment
        Hi,

        On Mon, Dec 02, 2002 at 05:04:35PM -0800, Loring Craymer wrote:
        > You're probably right that this is not a needed construct as long as the
        > AST Factory does the right thing about mapping token types to AST
        > classes. However, I'd much rather see AST construction and manipulation
        > abstracted from the target language as much as possible to support better
        > optimization of generated code and easier targeting of multiple output
        > languages. This is a step in that direction.

        I don't see your last point actually. I'm all in favour of abstracting the
        AST construction/manipulation away from the target language. But the thing
        is that I don't see how a way to circumvent the mapping from the token type
        to the AST class instance pointed to will help in abstracting things (I
        might even tend to say obfuscate).

        If it's just having a complete as possible interface in the AST factory
        then I'd say no problem. In other cases I'm far from convinced that there
        is any merit to this. Okay this may just be a difference in opinion in
        coding 'style'. So if you guys think it's no problem just go ahead ;)

        > It would probably be a good idea to generate a warning when the assigned
        > token mapping is overridden--I suspect that most overrides would be
        > associated with a token type change, anyway.

        Am I missing something here? Are talking Lexer or Parser/Treewalker here?
        In the case of lexer I'd rather opt to support heterogenous tokens in stead
        of another 'hack' (it kindoff feels like the hardcoded 'new SomeASTType();'
        calls we just got rid off).

        > I think that we should put some thought into ANTLR 3 support for
        > user-defined attributes (get/set ops, for example; automatic AST class
        > construction, for another). Attributes are usually not specific to a
        > target language and might as well be supported directly.

        I wish I had more time for discussions on these things and on working on
        antlr :(

        Cheers,

        Ric
        --
        -----+++++*****************************************************+++++++++-------
        ---- Ric Klaren ----- klaren@... ----- +31 53 4893722 ----
        -----+++++*****************************************************+++++++++-------
        "You can't expect to wield supreme executive power just because some
        watery tot throws a sword at you!"
        --- Monty Python and the Holy Grail
      Your message has been successfully submitted and would be delivered to recipients shortly.