[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please, support easy AST generation

From: Frank Heckenbach
Subject: Re: Please, support easy AST generation
Date: Wed, 19 Dec 2018 15:43:50 +0100

Kaz Kylheku wrote:

> I think the generation of *parse trees* can be automated.
> AST's omit information from (abstract away from) the parse tree.  There 
> are many ways to do that; it's not obvious how to automate it.
> One problem with parse trees is that there are often nodes that are just 
> empty place holders for precedence levels and such. E.g. an "expression" 
> is a the same time a "term", which is also a "factor" which happens to 
> be a "number". In the AST, maybe I just want the number!
> Like instead of (expression (term (factor (number 3)))), I want that 
> condensed to just 3.
> Automating this condensing is probably a good research project.
> That hierarchy of expression > term > factor > { number , ident } just 
> exists for the associativity-precedence parsing; it has nothing to do 
> with abstract syntax in which issues of associativity and precedence are 
> no longer relevant.
> Moreover, certain terminal symbols also exist only for parsing.
> The AST omits numerous terminal symbols as well as nonterminal symbols 
> that are found in the parse tree. E.g.: consider the rule:
>    expr : '(' expr ')'
> Here, we want the AST-generating action to just be
>    { $$ = $2; }
> We do not introduce a new internal node, and we don't propagate the ( ) 
> terminal symbols.
> This is based on the knowledge that (expr) is semantically identical to 
> expr; it just has punctuators that influence parsing.

I think much of this is possible using type information, see my
recent proposal
which actually explicitly addresses your last example.

In short, by declaring expression, term and factor of the same
semantic type, you could let the automatic builder know not to build
any node for these conversions, but just copy the values. And
declaring '(' and ')' without semantic type would allow them to be
silently discarded.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]