[antlr-interest] Source- v. Target-driven xforms (was: Re: New
article on StringTemplates and Treewalkers)
Gregg Reynolds
dev at arabink.com
Wed Jan 11 08:46:06 PST 2006
Sorry, meant to rename thread first time. A major correction below:
>
> Hi all,
>
> I'm relatively new to AntlrWorld, having (re)discovered it only a few
> weeks ago, and then discovered StringTemplate, which has since consumed
> most of my waking hours.
>
> I can't really follow the hairy details of this thread, but I think I
> see an abstract pattern. Please tell me if the following makes sense:
>
> The core issue is design strategy for language transformation. If we
> can think of a continuum of design options, then (possibly) we can put
> the Antlr strategy on one end, and the (Jazillion?) on the other.
>
> (I'm being very schematic here; perhaps the actual workings of antlr and
> jazillion don't fit the schema. Please advise.)
>
> We can call the Antlr approach "source-driven transformation"; the
> Jazillion approach "target-driven" transformation.
>
> By "source-driven", I mean that the process looks sth like:
>
> a. write grammar to parse source language
> b. generate source AST
> c. write (tree) transformation grammar that attaches actions to
> (AST) productions, producing either:
>
> c1. a target AST that can then be run through other
> transformers, in particular a pretty-printer; or
> c2. a text in the target language
>
> So in practice a source-driven strategy means writing code to feed into
> a parser generator. The driver will invoke the parser on a source text.
> Grammatical structure of the source text controls processing.
>
> By "target-driven" I mean a process that looks something like:
>
> For each element in the target language,
>
> a. write transformation logic mapping source elements to target
> element
> b. write (or generate) a "rule", which is a little parser to
> examine the source text for elements needed to generate said target
> element; attach transformations from (a) to production in the grammar
Clarification: "rule" = *set* of parsers; attach transformations from
(a) to these parsers.
>
> In practice a target-driven strategy means writing a set of rules
> (functions) to be called in turn at each token in the source text. I.e.
> Start with a target element and see if the corresponding source
> production(s) match(es); or, try to find the appropriate target element
> by testing various source productions. Source language structure
> controls processing within the driver itself.
Major correction for last sentence above: *Target* language structure
controls processing...
>
> The source-driven approach embeds target generation code in a source
> grammar; the target-driven approach embeds source-grammar in target
> generation code.
>
> I hope that is somewhere in the ballpark; it's nice and clean so it
> would be a shame if it was also stupid. ;) I think I understand how
> antlr works pretty well, but I'm not sure about the Jazillion approach.
>
> If this schema is accurate/useful, then I would suggest building on the
> paper "Why I don't Use..." to produce a more general consideration of
> the pros and cons of the respective approaches. Something like
> *"Language Transformation Strategies: Source-Driven v. Target-Driven in
> a Fight to the Death!"* As it stands, the article is interesting
> (though a bit hard to follow for somebody like me, w/out lots of parsing
> experience), but it sometimes gives (me at least) the impression of
> saying "my approach is better because, well, because I like it more".
> That's not necessarily a bad thing, but I gather that in large part
> that's because you find the one approach fits better with the way you
> think about the problem, which doesn't imply that it is a "better"
> approach. I'd like to see a more dispassionate consideration of the
> pros and cons. The "mental model" one needs for each strategy is
> obviously very important, but there are other considerations:
> efficiency, maintainability, etc. - the usual suspects.
>
> And of course the overalln approach could be generalized, i.e. design an
> abstract uber-language (cf. IDL). Then you can write one
> source->uberlang transformer per source lang, and one uberlang->target
> transformer per target language. I suppose somebody already does this
> (or has decided it's impossible or impractical).
>
> thanks,
>
> gregg
>
More information about the antlr-interest
mailing list