|Syntax tree generation under different parsing techniques firstname.lastname@example.org (Dave) (2004-04-21)|
|Re: Syntax tree generation under different parsing techniques email@example.com (Dmitry A. Kazakov) (2004-04-28)|
|Re: Syntax tree generation under different parsing techniques firstname.lastname@example.org (2004-05-16)|
|From:||"Dmitry A. Kazakov" <email@example.com>|
|Date:||28 Apr 2004 14:35:37 -0400|
|Posted-Date:||28 Apr 2004 14:35:37 EDT|
On 21 Apr 2004 00:50:47 -0400, "Dave" <firstname.lastname@example.org> wrote:
>I would like to decouple my parsing and translation (here, "translation"
>consists only of interpreting; I'm not actually generating code).
>Currently, I'm doing predictive recursive descent parsing, but I have to do
>some kludgy backtracking because there is one spot in the grammar that is
>not suitable for this parsing technique. My goal is to employ some other
>parsing technique and to generate a syntax tree while doing so (which I
>don't currently do; as I opened with, the translation is inline with the
>My question is: Regardless of the parsing technique used, is it always
>possible to generate a syntax tree? It just seems intuitive to me that some
>techniques don't lend themselves to the generation of a syntax tree. It's
>hard for me to articulate why, but it seems that way. For example, if I
>were to take the easy route and implement CYK, how well would it lend itself
>to generate a syntax tree? What about other techniques?
You might take at the infix expression parser in:
It does not use parsing tree, but can generate it. The technique uses
no grammar (at least explicitly) and based on an old infix to postfix
notation conversion algorithm.
Return to the
Search the comp.compilers archives again.