|yacc parse tree firstname.lastname@example.org (Josh Adams) (1998-12-10)|
|Re: yacc parse tree email@example.com (Simon Cozens) (1998-12-13)|
|Re: yacc parse tree firstname.lastname@example.org (1998-12-13)|
|Re: yacc parse tree email@example.com (1998-12-18)|
|Re: yacc parse tree firstname.lastname@example.org (1998-12-18)|
|Re: yacc parse tree email@example.com (Josh Adams) (1998-12-19)|
|Re: yacc parse tree firstname.lastname@example.org (Joachim Durchholz) (1998-12-19)|
|Re: yacc parse tree email@example.com (Sukru Cinar) (1998-12-21)|
|Re: yacc parse tree firstname.lastname@example.org (Sukru Cinar) (1998-12-22)|
|Re: yacc parse tree AMartin@ma.ultranet.com (Alan H. Martin) (1999-01-02)|
|[2 later articles]|
|From:||email@example.com (Bob McWhirter)|
|Date:||18 Dec 1998 12:10:38 -0500|
>> 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.
Return to the
Search the comp.compilers archives again.