Re: parse tree

[Hans Aberg]

At 13:06 -0400 2002/04/19, Aurelian Melinte wrote:
>>I am not sure what you are meaning here: The parsing tree depends on the
>>input; every language sentence has its own parsing tree.
...
>indeed, each node of the parsing tree will have generic informations (such
>as the text of the symbol if any and the line on which it was found) and
>infos specific to the grammar (for instance an integer saying which
>nonterminal/terminal is the node representing). Once I would have the tree,
>the analyze on it is language specific indeed.

Sorry, I did not read the rest of you post in detail.

The reason that Bison does not generate that is that it is a very
inefficient approach, even more so on the computers at the time when Bison
was first written (in the 80ies).

>I also start seeing the LALR difficulties Akim is pointing to me.

Bison is mainly a tool for writing fairly efficient parsers for the
languages that one typically encounters in daily life. It then contains
several tradeoffs:

LALR(1) provides a small lookup table, but it cannot catch the full LR(1)
algorithm. Further, in order to achieve this algorithm compactification,
errors may be merged, so that may not be reported immediately, even though
one is guaranteed that an error will never cause an additional reduce.

As a consequence, when using Bison to implement a language, one will
typically have to make several tweaks, which may include context shifts in
the lexer and certain duplication of grammar rules. (See the Bison manual
for an example on how to handle certain C constructs.)

>From your point of view, so then may get quite far from a beautiful static
parsing tree that describes the language semantics.

  Hans Aberg