[antlr-interest] Re: Seperating Grammar and Actions..

[John D. Mitchell]

>>>>> "micheal" == micheal jor <open zone at virgin net> <open.zone at virgin.net> writes:

>> I'm very much of the opinion that for any non-trivial translator, the
>> only thing that the parser should do is to build the AST and any
>> auxiliary data structures that only it can build and nothing else.
>> I.e., no syntax-directed, parser translators for anything that's
>> non-trivial.

> This can be interpreted as "strive for no [minimal?] embedded action code
> in parsers for non-trivial translators". Is this what you meant?

Basically.  The actions should only do what is necessary and sufficient so
as to be able build the initial AST (and any necessary auxiliary data
structures).  It's arguable whether things like symbol tables are really
necessary to build during the parse phase but, IMHO, that mostly depends on
the nature of the source language.


> <SNIPPED-stuff-I-agree-with/>

>> For many translators, that's just making passes over the AST and doing
>> annotation, pruning, rearrangement, and some insertions.  For others,
>> that's a basis from which to build additional auxiliary structures
>> (e.g., def-use, use-def chains) or more specialized IRs (e.g., machine
>> specific tuple formats).

> Can all the remaining work be specified as ANTLR tree parsers (this is
> related to my other post about resolvers-etc-as-treeparsers I guess) ?.

IME, that depends on the nature of your languages and what you want to do
the source.  For some projects, it's necessary to work with other back-end
libraries, etc. so it can depend on what they require.  For (most?) source
to source translators, the AST+ approach has been all that's needed.

Personally, I like having an AST as the primary IR and then create extra
data structures when they will make some particular task significantly
easier/faster/safer/etc.  That allows me to rely on the discipline and
rigor of grammar-based treewalkers as the backbone of the system.

[Aside: If you want to learn a lot of bad ways to deal with trees, look at
all of the flailing crap floating around in the XML world.  Ugh.]


> Any links/cites to information (particularly practical implementation
> related info) on some of these other passes and auxilliary structures
> please?

There are tons of papers floating around on stuff like this.  The various
books on compilers are very hit or miss depending on what you're looking
for.  The comp.compilers newsgroup is a great resource.

Note that very few of the papers and book deal with source to source
translation.  Most deal with the traditional compiler from source to object
code.  Though, with the popularity of Java, Perl, etc. more are playing
with the notion of executable IRs such as the Java Virtual Machine's
bytecode (.class) format and thinks like Just-In-Time and dynamic
compilers.  They all have slightly (or wildly) different usage constraints
and so solutions that make no sense in one context can be perfect for
another.

Hope this helps,
		John

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/