|Source-to-source transformation: best approach? email@example.com (SomeDeveloper) (2007-08-04)|
|Re: Source-to-source transformation: best approach? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2007-08-07)|
|Re: Source-to-source transformation: best approach? Meyer-Eltz@t-online.de (Detlef Meyer-Eltz) (2007-08-11)|
|Re: Source-to-source transformation: best approach? firstname.lastname@example.org (2007-08-11)|
|Re: Source-to-source transformation: best approach? cfc@shell01.TheWorld.com (Chris F Clark) (2007-08-12)|
|Re: Source-to-source transformation: best approach? email@example.com (Jim Cordy) (2007-08-14)|
|Date:||Sat, 04 Aug 2007 03:51:06 -0000|
I gather that TXL (http://www.txl.ca/) is being used by many for
source to source transformations, and though I'm now somewhat
comfortable with the language, as primarily a non-compilers person, I
don't know why TXL would be especially suited for source to source
- Is it because, that unlike yacc/bison, it allows ambiguous task-
specific (agile) grammars?
- Can't we write 'agile' grammars in yacc/bison/antlr (by ignoring
tokens/constructs that are outside the scope of the task at hand)?
- Wouldn't we be able to meet all our agile source transformation
needs with, for example, Parse:RecDescent, a recursive descent for
Basically, I do not know what conceptual 'dead-end' I'd run into in
future if today I were to choose a recursive descent parser such as
RecDescent for my long-term source to source transformation needs.
Similarly, I don't know what would go wrong (or become difficult /
unweildy) if I were to choose antlr, specifically for source to source
Since this question of mine spans breadth as well as depth of the
field of compilers, I'd greatly appreciate if folks here could share
some insights / info / links on this.
[The main advantage of TXL is that it has a lot of I/O and tree
building as part of the languge, whereas you have to implement
them yourself if you used a yacc parser. -John]
Return to the
Search the comp.compilers archives again.