[antlr-interest] Dilemma

mzukowski at yci.com mzukowski at yci.com
Tue Jun 10 08:37:55 PDT 2003


Number 2 is probably the most powerful.  Note that you should be able to
reconstruct a whole region of text given a tree.  You aren't limited to only
putting text into AST nodes, you can put anything you want in by making your
own node subclass.  See the gcc parser for an example of this.
http://www.codetransform.com/gcc.html.  

Concrete examples would help me think this through.

Monty

-----Original Message-----
From: j_scandaliaris at yahoo.es [mailto:j_scandaliaris at yahoo.es] 
Sent: Tuesday, June 10, 2003 4:15 AM
To: antlr-interest at yahoogroups.com
Subject: [antlr-interest] Dilemma


Hi all,
	I have an antlr recognizer already built. Now I am adding actions to
produce the output, which is the generation of a tree (not an AST, it is a
custom tree-structure representing the hierarchy of the source code). I
decided to build the tree manually, mostly because I don't have control over
it, only access to the methods for creating it. From the input source code
the important thing is to recognize some key structures which are the inputs
to the tree construction methods, mainly names, numbers and portions of the
source code (in the form of strings).
	
	The dilemma I face is to find the simplest (performance not
critical) way to do this (the grammar has already some 2000 lines and over
200 rules). The basic problems I face are that the grammar decomposes a rule
(for which I have some tree construction method) into several levels of
calls to other sub rules. Each sub rule will match some text (a name, a list
of names, or more complex structures) and then I have to return this info
back to the main rule in some way. This is the key point. I have devised so
far several ways of doing this (in each case with some limitations):
	
	1. Use rule return values. -> Cumbersome when the sub rule is n
levels below. One possible return value; when in need to return multiple
things they have to be grouped; manually done all the way
	2. Use AST= true and take advantage of nodes' text as a sort of
antlr-managed string-type return value. -> Limited to strings, still a bit
cumbersome when sub rule is deep down in the call hierarchy, adds a lot of
overhead.
	3. Create some data members in the parser class or some automatic
objects within the class' rules, and communicate through them. -> Difficult
to follow, I think it might be prone to hide bugs.
	
	So far my ideas, right now I might be going for a combination of 2
and 3, but I am looking forward to learning from other people's experience
and knowledge. Any help is appreciated,

Regards,

Jorge


 

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


 

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




More information about the antlr-interest mailing list