|Usefulness of automatic parse tree generation email@example.com (2004-07-13)|
|Re: Usefulness of automatic parse tree generation firstname.lastname@example.org (Ira Baxter) (2004-07-13)|
|Re: Usefulness of automatic parse tree generation email@example.com (Carl Cerecke) (2004-07-13)|
|Re: Usefulness of automatic parse tree generation firstname.lastname@example.org (Dave) (2004-07-17)|
|Re: Usefulness of automatic parse tree generation email@example.com (Paul B Mann) (2004-07-28)|
|Date:||13 Jul 2004 10:52:30 -0400|
|Posted-Date:||13 Jul 2004 10:52:30 EDT|
I'd like to solicit opinions on a particular idea from people with
experience in the compilers field.
I'm in the process of writing a generic SLR parser. It takes as input
SLR parsing tables and a string to be parsed. Currently, it's output
is the sequence of rule invocations that will yield the input string
(or an error if the string is not in the language).
The question I have is with regard to the output. I'm considering
also having it output a parse tree. Of course, as a generic library,
the only thing it could do would be to output a parse tree that
exactly mimicked the grammar and the particular derivation arrived at.
So, leaves would represent tokens and interior vertices and the edges
coming from them would represent a grammar rule invocation.
Often times, people want a parse tree that is more compact than that
described above. For example, parsing the expression "5 + 5" might
yield a tree with three vertices: a root node representing "+" with
two children each representing 5. My approach would yield a much
larger tree if the grammar had many levels getting down to a number
token. And this would typically be the case in a grammar representing
expressions with operators at many different precedence levels...
So, my question is: How useful would my idea be? In what contexts
would it be useful to have a tree that mimicked the grammar and a
particular derivation with that grammar? In what contexts would it
not be useful? Is it worth implementing?
I appreciate any input.
Return to the
Search the comp.compilers archives again.