Related articles |
---|
yacc parse tree josh_adams@bmc.com (Josh Adams) (1998-12-10) |
Re: yacc parse tree simon.cozens@pembroke.oxford.ac.uk (Simon Cozens) (1998-12-13) |
Re: yacc parse tree mikesw@whiterose.net (1998-12-13) |
Re: yacc parse tree bob@werken.com (1998-12-18) |
Re: yacc parse tree belinfan@cs.utwente.nl (1998-12-18) |
Re: yacc parse tree josh_adams@bmc.com (Josh Adams) (1998-12-19) |
Re: yacc parse tree joachim.durchholz@munich.netsurf.de (Joachim Durchholz) (1998-12-19) |
Re: yacc parse tree scinar@ug.bcc.bilkent.edu.tr (Sukru Cinar) (1998-12-21) |
Re: yacc parse tree scinar@ug.bcc.bilkent.edu.tr (Sukru Cinar) (1998-12-22) |
Re: yacc parse tree AMartin@ma.ultranet.com (Alan H. Martin) (1999-01-02) |
[2 later articles] |
From: | bob@werken.com (Bob McWhirter) |
Newsgroups: | comp.compilers |
Date: | 18 Dec 1998 12:10:38 -0500 |
Organization: | werken digital |
References: | 98-12-018 98-12-022 |
Keywords: | parse, tools |
>> pretty simple. Each rule takes the subtrees from its subrules and
>> tokens and builds a tree for that rule and returns it as $$. When you
>> get to the top, you have a parse tree. The most annoying part is
>> allocating and deallocating the tree nodes, particularly if you want
>> to recover from parse errors.
SC> I imagine Knuth would have a clever data-structure based solution to this
SC> one - is anyone aware of any work done on the idea of the parser
SC> constructing a *tree of trees*?
As this is exactly what goes on with PCCTS in constructing ASTs,
several users (myself included) have resorted to using a factory
method to create the nodes of the trees. The factory maintains a list
of all nodes created.
If during the parse, an error occurs or otherwise nodes end up not
connected to the final tree, the factory just walks the resulting
tree, accounting for the nodes in its list of all created nodes,
deleting any that aren't accounted for when all is said and done.
Simple memory management, really.
-Bob
Return to the
comp.compilers page.
Search the
comp.compilers archives again.