[antlr-interest] ANTLR 3.0 tree construction proposal

[Terence Parr]

On Feb 1, 2005, at 3:24 PM, John D. Mitchell wrote:

> Re:  ^^
>
> It's about time!  :-)

Hooray!

> I don't like the change of semantics for ^ but I must agree with the
> argument that ^^ makes more sense for the rule root and ^ for the local
> root.

Yeah, an imperfect but acceptable solution.

> Re:  ->
>
> Definitely better than =>.

Yep.

> Re:  Tree rewrites
>
> (A) Getting rid of the e.g., #(...) is good by me.
>
> (B) I'm concerned by the need to repeat the arguments in the RHS such 
> as in:
>
> decl : "var" (ID ':' type ';')+ -> ^("var" ^(':' ID type)+) ;
>
> What happens when there's two "var"s?  Which "var" is going to be used 
> as
> the basis on the RHS?

it depends on how many times it's matched on the left.  If matched once 
then only one "var" node will appear in the rewrite.

> Heck, what about typos?
>
> [Yes, I understand that they can be explicitly labeled -- I'm asking 
> about
> these "simple" cases.]

Typos will always be a problem if you ref something improperly.  if 
it's a nonexistent entity, i can give an error.

> Re: Imaginary Nodes
>
> I find the LPAREN[] utterly distasteful and expect that it will cause 
> hard
> to see errors.

Yeah, it's not so great, but it is like a ctor call with no args right? 
  We'll need ID["foo"] for example to create an ID node with a text 
value of "foo".

> Re: Actions in rewrite rules
>
> You need to expand/clarify that section in your document.

Thanks...

> Re: Rewrite specs in subrules
>
> No, I don't buy either of your arguments.
>
> I think it's more clear and controllable to (finally) support 
> labelling the
> subrules.  The subrule rewrites are then constrained to be bound to the
> label which is used in the overall rewrite rule for the rule.

I could buy that.  Labeled subrules should be easy enough to implement 
and *should* solve lots of problems.  Then we'd not need -> in 
subrules, right?  Well, wait, hmm...not sure we can use syntax to drive 
different tree construction easily.  I suppose if you could label a 
subrule and then ref label.ID for the ID tokens matched within labeled 
subrule.  Hmm... interesting.

> Re: Attribute integration
>
> As I've noted previously, I don't like the co-mingling of the dynamic
> attributes and the local attributes.  I think it's important that those
> separate but related constructions appear distinct from each other.

Can you be more specific?  We may have differing ideas of what those 
terms mean ;)

> Re: Rewrite dependent on semantics
>
> (A) I like the use of semantic predicates for this.
>
> (B) Is it just me or is the ? at the end of the semantic predicates
> ridiculously hard to see?  I'd love to see that move to be a prefix, 
> i.e.,:
>   ?{...}
> The left edge is (with any non-insane formatting convention) always 
> easier
> for humans to scan and parse.

True, but that argues for *(...) and +(...) too :)

> Re: Other Issues that I didn't see addressed in your blog...
>
> (A) Payload games
>
> Hmm... Don't we need to support the ability to treat the payload as 
> e.g., a
> list of payloads?  I.e., I'd like the first payload in the AST node to 
> be
> the e.g., Token but then I want to add annotations that are tied to 
> that
> node (rather than building e.g., a map).
>
>
> (B) Tree to tree transformations basics
>
> Basic question: is anything that you're thinking of doing going to 
> make it
> (a) easier, clearer, etc. or (b) more confusing, harder, etc. in the
> multiple tree-to-tree phases?

I'm still thinking about that, but tree->tree transformations should 
look the same as parser->tree construction.

> (C) Tree surgery
>
> Moving beyond the simplistic cases in (A), all of the interesting work
> being done in tree tranforms is real surgery of the tree.  I.e.,
> transformations which take place across a number of rules working in
> conjunction.
>
> A couple of areas that come immediately to mind are the need for 
> labelled
> subrules and being able to pass (and use) trees (aka tree fragments) 
> around
> in dynamic attributes (both down/inherited and up/synthesized) and as
> parameters/return values.

Yes, I want to be able to reference tree fragments via attribute 
mechanism.

> (D) Error handling
>
> You haven't gone into how the error handling would work with this.

Yeah, I need a few examples to think this through.

Thanks!

Ter
--
CS Professor & Grad Director, University of San Francisco
Creator, ANTLR Parser Generator, http://www.antlr.org
Cofounder, http://www.jguru.com