[antlr-interest] Antlr v3: Trees

[Tiller, Michael (M.M.)]

This reminds me of a few other issues:

1) Because I've had a fair amount of difficulty with the current C++
implementations for heterogenous ASTs, I'm working on a project where I
would like to be able to formally output the AST in XML so it can be read in
by other tools.  It would be nice if ANTLR3 could somehow support that.
Here are some ideas of how this could be done:

  1a) Allow the grammar (and node type definitions) to be marked up with
information about how the nodes should be translated to XML.  Specifically,
allow the developer to map different AST node types in ANTLR to different
XML element types.
  1b) Given the grammar information, it might be possible to examine the
action rules to generate a DTD for the generated XML automatically (probably
quite a bit of work though).
  1c) Allow high-level descriptions of AST node types that distinguish
between "attributes" and "children".  By this I mean that if I'm parsing a
number or a boolean piece of information, it would be nice to store it as an
attribute of a node rather than as a child.  The distinction is that
children are dynamic (you don't know how many, if any, you might end up
with).  Attributes are fixed...if you have this node, you have one of each
of these attributes.  One of the main reasons I prefer Heterogenous ASTs is
because they allow me to make this distinction.

2) I'm working with a group that uses "Natural Semantics"
(http://www.modelica.org/papers/scs98sem.pdf).  It seems like where ANTLR
transformations take the approach of having multiple passes (from one tree
grammar to another), this natural semantics approach expresses the process
differently by allowing you to define rules from the start to the end.  The
interesting thing, to me, is that the latter seems like it opens up the
possibility of automatically and completely identifying holes in the
complete transformation process from these sets of rules.  I mention it
because I agree that ANTLR's strength is in the tree handling and I just
wonder if users out there might benefit from having these kinds of
capabilities available to them (as a next step beyond the current tree
parsing capability).

I should add that, all this being said, I'm not really a "professional"
compiler developer and, frankly, know very little about what serious users
need.  As such, I understand if these ideas/requirements are considered low
priority (or even misdirected :-).  If I had to pick one thing in this list
that was most important to me, it would be 1c.

--
Mike

> -----Original Message-----
> From: John D. Mitchell [mailto:johnm-antlr at non.net]
> Sent: Wednesday, March 17, 2004 12:21 PM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Antlr v3: Trees
> 
> 
> I know that a major overhaul is coming on the tree handling 
> stuff but I
> just wanted to state publically that this is, to me, *the* 
> area where Antlr
> can really make a huge difference to the state of practice.
> 
> Grammar-based tree transformation is great not just for the 
> traditional
> language "compiler" world but is also key to cleaning up all 
> of the ad hoc
> tree crap that people are doing as part of the tidal wave of XML.
> 
> Speaking of XML, I think that it's critical to make sure that Antlr v3
> efficiently and effectively supports XML recognition, validation, and
> transformation.
> 
> Go wild,
> 	John
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
     antlr-interest-unsubscribe at yahoogroups.com

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