[antlr-interest] ANTLR 3.0 tree construction proposal
Terence Parr
parrt at cs.usfca.edu
Thu Feb 3 17:40:35 PST 2005
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
More information about the antlr-interest
mailing list