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) |
[4 later articles] |
From: | Simon Cozens <simon.cozens@pembroke.oxford.ac.uk> |
Newsgroups: | comp.compilers |
Date: | 13 Dec 1998 13:46:49 -0500 |
Organization: | vacant, like a toilet. |
References: | 98-12-018 |
Keywords: | parse, yacc, comment |
Josh Adams (comp.compilers): (Well, John, actually...)
> 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.
I imagine Knuth would have a clever data-structure based solution to this
one - is anyone aware of any work done on the idea of the parser
constructing a *tree of trees*?
--
[Any tree is a tree of trees, it's a recursive data structure. No cleverness
required here. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.