[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