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

treecc: AOP Approach to Writing Compilers

Expand Messages
  • Alexey Demakov
    I ve found another tool for specification of heterogenous tree http://www.southern-storm.com.au/treecc.html It uses AOP approach mentioned during our
    Message 1 of 8 , Nov 24, 2004
      I've found another tool for specification of heterogenous tree
      http://www.southern-storm.com.au/treecc.html

      It uses AOP approach mentioned during our discussion on tree processing:
      http://www.southern-storm.com.au/treecc_essay.html

      Very interesting, I wonder why haven't seen it before.

      It is used in DotGNU Portable.NET, so seems to be stable enough.

      Btw, I've just released TreeDL 1.0...

      Regards,
      Alexey

      -----
      Alexey Demakov
      TreeDL: Tree Description Language: http://treedl.sourceforge.net
      RedVerst Group: http://www.unitesk.com
    • micheal_jor
      ... I looked at it a couple of years ago. It seemed easy to use and useful but it was tied to a Yacc-ish way of life. Sigh... I didn t get the AOP-ness though.
      Message 2 of 8 , Nov 24, 2004
        --- In antlr-interest@yahoogroups.com, "Alexey Demakov" <demakov@i...>
        wrote:
        > I've found another tool for specification of heterogenous tree
        > http://www.southern-storm.com.au/treecc.html
        >
        > It uses AOP approach mentioned during our discussion on tree processing:
        > http://www.southern-storm.com.au/treecc_essay.html
        >
        > Very interesting, I wonder why haven't seen it before.

        I looked at it a couple of years ago. It seemed easy to use and useful
        but it was tied to a Yacc-ish way of life. Sigh...

        I didn't get the AOP-ness though. I though it was just a tree builder.
        Perhaps I missed something.

        Micheal
        ANTLR/C#
      • Alexey Demakov
        From: micheal_jor ... I don t see any dependencies on yacc. Only % in notation. But I m reading treecc docs only about a hour :) ...
        Message 3 of 8 , Nov 24, 2004
          From: "micheal_jor" <open.zone@...>
          > --- In antlr-interest@yahoogroups.com, "Alexey Demakov" <demakov@i...>
          > wrote:
          > > I've found another tool for specification of heterogenous tree
          > > http://www.southern-storm.com.au/treecc.html
          > >
          > > It uses AOP approach mentioned during our discussion on tree processing:
          > > http://www.southern-storm.com.au/treecc_essay.html
          > >
          > > Very interesting, I wonder why haven't seen it before.
          >
          > I looked at it a couple of years ago. It seemed easy to use and useful
          > but it was tied to a Yacc-ish way of life. Sigh...

          I don't see any dependencies on yacc. Only % in notation.
          But I'm reading treecc docs only about a hour :)

          > I didn't get the AOP-ness though. I though it was just a tree builder.
          > Perhaps I missed something.

          The second link describes the tree?? way of tree processing.

          Regards,
          Alexey

          -----
          Alexey Demakov
          TreeDL: Tree Description Language: http://treedl.sourceforge.net
          RedVerst Group: http://www.unitesk.com
        • John D. Mitchell
          ... [...] ... Hmm... Sorry but I really don t understand your AOP comments either. Can you explain with more detail? Certainly there are natural aspects
          Message 4 of 8 , Nov 24, 2004
            >>>>> "Alexey" == Alexey Demakov <demakov@...> writes:
            [...]

            >> I didn't get the AOP-ness though. I though it was just a tree builder.
            >> Perhaps I missed something.

            > The second link describes the tree?? way of tree processing.

            Hmm... Sorry but I really don't understand your "AOP" comments either. Can
            you explain with more detail?

            Certainly there are natural "aspects" in a grammar based approach such as
            the grammar structure itself but I'm certainly not going to call that AOP
            compiler writing.

            Thanks,
            John
          • Tiller, Michael (M.M.)
            Alexey, Thanks for posting this. This is quite interesting. Many of my ML friends gush about being able to do things like this in ML. I suspect there is
            Message 5 of 8 , Nov 24, 2004
              Alexey,

              Thanks for posting this. This is quite interesting. Many of my ML
              friends gush about being able to do things like this in ML. I suspect
              there is room to bring the sort of exhaustive pattern machine and
              high-level type descriptions of ML into a more mainstream environment
              like ANLTR.

              Have you given any thought to implementing these kinds of pattern
              matching features in TreeDL?! I'm already quite interested in TreeDL
              but pattern matching capabilities would be a fascinating addition.

              I'm no compiler expert, but I can't help but see lots of related but
              not quite cohesive ideas floating around on this subject. The recent
              thread on tree grammars (to use or not to use) plus the comments I've
              gotten from my ML friends along with my own experiences gives me the
              sense that perhaps there is a way to formulate these ideas in a more
              universal way. Personally, I like the pattern matching approach in ML
              because it seems like something that can be analyzed more (e.g. for
              holes) than a tree grammar. It also seems like it maps more to the
              compilation stages (type inference, constant folding, etc). But I'll
              say it again "I'm no compiler expert".

              Thanks again.

              P.S. - I don't quite see the AOP part of Treecc. It really just seems
              like a high-level data model language that supports code generation for
              the underlying data structures. Of course, I still don't get AOP so
              maybe that is why I can't see it.

              --
              Mike

              > -----Original Message-----
              > From: Alexey Demakov [mailto:demakov@...]
              > Sent: Wednesday, November 24, 2004 11:29 AM
              > To: ANTLR
              > Subject: [antlr-interest] treecc: AOP Approach to Writing Compilers
              >
              >
              > I've found another tool for specification of heterogenous tree
              > http://www.southern-storm.com.au/treecc.html
              >
              > It uses AOP approach mentioned during our discussion on tree
              processing:
              > http://www.southern-storm.com.au/treecc_essay.html
              >
              > Very interesting, I wonder why haven't seen it before.
              >
              > It is used in DotGNU Portable.NET, so seems to be stable enough.
              >
              > Btw, I've just released TreeDL 1.0...
              >
              > Regards,
              > Alexey
              >
              > -----
              > Alexey Demakov
              > TreeDL: Tree Description Language: http://treedl.sourceforge.net
              > RedVerst Group: http://www.unitesk.com
              >
              >
              >
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
            • micheal_jor
              ... ... That [dependency] seems to have disappeared (or perhaps I was wrong and it never existed). I see treecc can now generate code for languages
              Message 6 of 8 , Nov 24, 2004
                --- In antlr-interest@yahoogroups.com, "Alexey Demakov" <demakov@i...>
                wrote:

                > > > I've found another tool for specification of heterogenous tree
                > > > http://www.southern-storm.com.au/treecc.html

                <SNIP>

                > > I looked at it a couple of years ago. It seemed easy to use and useful
                > > but it was tied to a Yacc-ish way of life. Sigh...
                >
                > I don't see any dependencies on yacc. Only % in notation.
                > But I'm reading treecc docs only about a hour :)

                That [dependency] seems to have disappeared (or perhaps I was wrong
                and it never existed). I see treecc can now generate code for
                languages other than C too. Treecc has changed a lot I see...

                > > I didn't get the AOP-ness though. I though it was just a tree builder.
                > > Perhaps I missed something.
                >
                > The second link describes the tree?? way of tree processing.

                I read both. Can't quite agree it's AOP. Nevermind, it seems useful
                [at last] in any case. One for the check-this-out list...

                Cheers!

                Micheal
              • Alexey Demakov
                From: Tiller, Michael (M.M.) ... Unfortunately, I m not familiar with ML :( ... Generally, yes. But I think it is more operation over
                Message 7 of 8 , Nov 25, 2004
                  From: "Tiller, Michael (M.M.)" <mtiller@...>
                  > Thanks for posting this. This is quite interesting. Many of my ML
                  > friends gush about being able to do things like this in ML. I suspect
                  > there is room to bring the sort of exhaustive pattern machine and
                  > high-level type descriptions of ML into a more mainstream environment
                  > like ANLTR.

                  Unfortunately, I'm not familiar with ML :(

                  > Have you given any thought to implementing these kinds of pattern
                  > matching features in TreeDL?! I'm already quite interested in TreeDL
                  > but pattern matching capabilities would be a fascinating addition.

                  Generally, yes. But I think it is more 'operation over subtree' than
                  pattern matching. In my understanding, pattern matching proposes that you
                  specify more than just a node - may be children types or attribute values -
                  and some engine searches tree and executes your actions in context
                  of matched pattern. I don't like such engine, because prefer
                  to control order of tree walking.

                  When processing a tree, we need some natural way to specify actions over
                  tree as a whole or some subtree. Action, like usual method, have signature.
                  Because of heterogenous tree description we don't need to repeat
                  full tree structure as in ANTLR tree grammars.
                  But action body should be defined for each inherited node type with ability
                  to use super-implementation. Translation tool should check consistence
                  of action definition.

                  > I'm no compiler expert, but I can't help but see lots of related but
                  > not quite cohesive ideas floating around on this subject. The recent
                  > thread on tree grammars (to use or not to use) plus the comments I've
                  > gotten from my ML friends along with my own experiences gives me the
                  > sense that perhaps there is a way to formulate these ideas in a more
                  > universal way. Personally, I like the pattern matching approach in ML
                  > because it seems like something that can be analyzed more (e.g. for
                  > holes) than a tree grammar. It also seems like it maps more to the
                  > compilation stages (type inference, constant folding, etc). But I'll
                  > say it again "I'm no compiler expert".

                  Can you write some short review of ML features that can be useful for tree
                  processing? At least ideas. Or point me to existing document.
                  I'll try to read something about ML, but not sure can find time :(

                  > P.S. - I don't quite see the AOP part of Treecc. It really just seems
                  > like a high-level data model language that supports code generation for
                  > the underlying data structures. Of course, I still don't get AOP so
                  > maybe that is why I can't see it.

                  Well, every answer on my message contains similar statement.
                  Let it be on conscience of author of "Treecc: An Aspect-Oriented Approach to Writing Compilers" :)
                  May be it is not AOP in usual sence, but I see some similarity.

                  Regards,
                  Alexey

                  -----
                  Alexey Demakov
                  TreeDL: Tree Description Language: http://treedl.sourceforge.net
                  RedVerst Group: http://www.unitesk.com
                • Tiller, Michael (M.M.)
                  Alexey et. al., I forwarded this discussion on to a colleague who is more familiar with using ML for compiler writing. He pointed out some stuff I wasn t
                  Message 8 of 8 , Dec 16, 2004
                    Alexey et. al.,

                    I forwarded this discussion on to a colleague who is more familiar
                    with using ML for compiler writing. He pointed out some stuff I wasn't
                    aware of.

                    What I would like to see is something with the pattern matching
                    capabilities of ML (succinct action descriptions, exhaustive
                    combinatorial analysis, etc.). Granted, tree parsers are one way to go.
                    But my colleague also pointed out the following language:

                    Scala - http://scala.epfl.ch/
                    Nice - http://nice.sourceforge.net/

                    To me the really neat part about these languages is that I can layer
                    them over the Java virtual machine and work directly with Java objects.
                    Perhaps it is more aesthetics than anything else, but it seems quite
                    elegant to me.

                    Alexey, I wonder if you could exploit the descriptions in treecc to
                    generate code for these languages as well?

                    I also found some discussions on these here:

                    http://www.manageability.org/blog/stuff/scala-the-groovy-killer/view

                    Note that I don't really have any concrete proposals. These ideas are
                    still swirling around in my head at the moment. I just find that these
                    various approaches have different aspects that I like and I just wonder
                    if there is a way to combine them to get the best of all worlds.

                    --
                    Mike

                    > -----Original Message-----
                    > From: Alexey Demakov [mailto:demakov@...]
                    > Sent: Thursday, November 25, 2004 11:40 AM
                    > To: antlr-interest@yahoogroups.com
                    > Subject: Re: [antlr-interest] treecc: AOP Approach to Writing
                    Compilers
                    >
                    >
                    > From: "Tiller, Michael (M.M.)" <mtiller@...>
                    > > Thanks for posting this. This is quite interesting. Many of my
                    ML
                    > > friends gush about being able to do things like this in ML. I
                    suspect
                    > > there is room to bring the sort of exhaustive pattern machine and
                    > > high-level type descriptions of ML into a more mainstream
                    environment
                    > > like ANLTR.
                    >
                    > Unfortunately, I'm not familiar with ML :(
                    >
                    > > Have you given any thought to implementing these kinds of pattern
                    > > matching features in TreeDL?! I'm already quite interested in
                    TreeDL
                    > > but pattern matching capabilities would be a fascinating addition.
                    >
                    > Generally, yes. But I think it is more 'operation over subtree' than
                    > pattern matching. In my understanding, pattern matching proposes that
                    you
                    > specify more than just a node - may be children types or attribute
                    values
                    > -
                    > and some engine searches tree and executes your actions in context
                    > of matched pattern. I don't like such engine, because prefer
                    > to control order of tree walking.
                    >
                    > When processing a tree, we need some natural way to specify actions
                    over
                    > tree as a whole or some subtree. Action, like usual method, have
                    > signature.
                    > Because of heterogenous tree description we don't need to repeat
                    > full tree structure as in ANTLR tree grammars.
                    > But action body should be defined for each inherited node type with
                    > ability
                    > to use super-implementation. Translation tool should check consistence
                    > of action definition.
                    >
                    > > I'm no compiler expert, but I can't help but see lots of related
                    but
                    > > not quite cohesive ideas floating around on this subject. The
                    recent
                    > > thread on tree grammars (to use or not to use) plus the comments
                    I've
                    > > gotten from my ML friends along with my own experiences gives me the
                    > > sense that perhaps there is a way to formulate these ideas in a more
                    > > universal way. Personally, I like the pattern matching approach in
                    ML
                    > > because it seems like something that can be analyzed more (e.g. for
                    > > holes) than a tree grammar. It also seems like it maps more to the
                    > > compilation stages (type inference, constant folding, etc). But
                    I'll
                    > > say it again "I'm no compiler expert".
                    >
                    > Can you write some short review of ML features that can be useful for
                    tree
                    > processing? At least ideas. Or point me to existing document.
                    > I'll try to read something about ML, but not sure can find time :(
                    >
                    > > P.S. - I don't quite see the AOP part of Treecc. It really just
                    seems
                    > > like a high-level data model language that supports code generation
                    for
                    > > the underlying data structures. Of course, I still don't get AOP so
                    > > maybe that is why I can't see it.
                    >
                    > Well, every answer on my message contains similar statement.
                    > Let it be on conscience of author of "Treecc: An Aspect-Oriented
                    Approach
                    > to Writing Compilers" :)
                    > May be it is not AOP in usual sence, but I see some similarity.
                    >
                    > Regards,
                    > Alexey
                    >
                    > -----
                    > Alexey Demakov
                    > TreeDL: Tree Description Language: http://treedl.sourceforge.net
                    > RedVerst Group: http://www.unitesk.com
                    >
                    >
                    >
                    >
                    >
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                    >
                    >
                  Your message has been successfully submitted and would be delivered to recipients shortly.