[antlr-interest] Re: Source-driven v. Target-driven xforms (was
Re: New article on StringTemplates and Treewalkers)
Gregg Reynolds
dev at arabink.com
Wed Jan 11 10:22:25 PST 2006
Andy Tripp wrote:
> Hi Gregg,
>
> Yes, very good description of the issue.
> Generally, I think of it as "tree driven" vs. "rule driven" rather than
> "source-driven"
> and "target driven". In "tree driven", the source language grammar
> drives the design.
> In rule-driven, the design is a sequential application of rules.
>
Understandable, but as I mentioned in my other post, "rule" is
ambiguous, so this terminology might be troublesome for people not so
familiar with parsing or your approach. In ParserWorld, "rule" is
commonly a synonym for "grammatical production" (which may have attached
actions) (and it could be a tree grammar production), but in
JazillionTown it means specifically a function that does a little
parsing and then some actions. I think that will be confusing for your
readers. Unfortunately I can't think of a better term at the moment.
Howsabout "target-centered rule-driven" v. "source-centered
tree-driven"? Oh boy! Acronyms: TCRD v. SCTD! ;)
A Jazillion "rule" is analogous to an antlr "rule" turned inside out,
and vice-versa, no?
But "tree-driven" makes sense to me, since it creates and uses ASTs,
whereas Jazillion doesn't.
>
> When I started with the tree-driven approach and using ANTLR to do
> tranformation, I felt completely bogged down in
> AST structure and found myself constantly thinking about *how* to do
> things rather than what needed
> to be done.
>
Well, that's where I have to hold my tongue, since it's all theoretical
to me. But as a general issue, I wonder how much of that is
attributable to Antlr's meta-language, by which I mean the English
language used to document the works. After all, anybody who can read C
and understand C code must be parsing it, and therefore must have a
structured model of the code rattling around in the skull: a tree, if
not an AST. If one sees "if (x=1)", one can surely see that "x=1" is an
expression, and that it is composed of a variable, etc. Which amounts
to a tree, even if one doesn't use tree language (parent, child, root,
etc.) to talk about it.
In any case, I think you've put your finger on a very important point,
namely that even if the AST-based approach has advantages, it may
require the fabled "paradigm shift", and let's face it, most people
coding to deadline don't have the luxury - it takes time, and there's
always the risk that the new paradigm won't deliver. So then the
question is, can the AST approach be explained in a metalanguage that is
closer to the way most programmers ordinarily think? By the same token,
can we come up with a meta-language for your approach that connects it
with the implied parse tree/AST? Hmm. (If you can't tell, I'm actually
much more interested in the expressiveness of language and metalanguage
than I am in actual software. ;)
-gregg
More information about the antlr-interest
mailing list