[antlr-interest] ANTLR 3.0 tree construction proposal

[John D. Mitchell]

Re:  ^^

It's about time!  :-)

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.


Re:  ->

Definitely better than =>.


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?

Heck, what about typos?

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

(C) I haven't used Loring's stuff so I'm going to re-read his comments in
this thread and think about them.


Re: Imaginary Nodes

I find the LPAREN[] utterly distasteful and expect that it will cause hard
to see errors.


Re: Actions in rewrite rules

You need to expand/clarify that section in your document.


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.


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.


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.


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?


(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.


(D) Error handling

You haven't gone into how the error handling would work with this.


Thanks,
	John