Related articles |
---|
Parser question mike@sesamgames.com (Mike \(News\)) (2008-07-11) |
Re: Parser question avron2006b@yahoo.com (Aeran) (2008-07-13) |
Re: Parser question max@gustavus.edu (Max Hailperin) (2008-07-13) |
Re: Parser question DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-07-15) |
Re: Parser question mikael@sesamgames.com (Mikael =?ISO-8859-1?Q?Str=F6m?=) (2008-07-17) |
Re: Parser question max@gustavus.edu (Max Hailperin) (2008-07-19) |
From: | Hans-Peter Diettrich <DrDiettrich1@aol.com> |
Newsgroups: | comp.compilers |
Date: | Tue, 15 Jul 2008 12:42:11 +0200 |
Organization: | Compilers Central |
References: | 08-07-024 |
Keywords: | parse |
Posted-Date: | 19 Jul 2008 14:43:15 EDT |
Mike (News) schrieb:
> The implementation is a predictive parser that construct a syntax tree
> holding both expression and statements. As the grammar is recursive,
> so is the implementation. However, i wish to find some shortcuts to
> rewrite (at least some of) the recursive functions to be
> iterative. Are there any well known algorithms of doing this?
> For instance the grammar for:
>
> expr -> term moreterms
>
> moreterms -> + term | - term | N5
>
>
> Is inherently recursive. How would I write iterative code for this using
> my tree function makenode_op(operand, left, right)?
One method would "flatten" the operator hierarchy, to essentially only
one unary and binary operator class, covering all operators:
moreterms -> binop term | epsilon
Then something like an internal list (usually stack) of operators and
terms is produced by moreterms, that is "folded" into an tree before
exit, based on the operator precedence, grouping etc.
Otherwise indirect recursion may not be eliminated, by tail recursion or
a conversion of distinct productions.
DoDi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.