Maybe my comment is rather late. Forgive me if it is unrelated to the current
discussions.
I have been doing the AST generation from Bison for some time since the YAXX
subproject.
There the initial aim was to output the parsing trees as XML and some people
liked that.
But occasionally I received questions on how to do this for ASTs. At that time
I was not
Bison maintainer so the approach I took was to do this as a change to the
“yacc.c” template
and keep everything else the same.
The actions to decide whether a parsing tree node (or I call it element in the
XML counterpart)
is worthy to keep or not. If they are not, I simply do no generate the tags,
similar to what you
propose for conditionally prints.
The nice thing of this approach is it is lightweight in terms of maintenance
effort, if all you
want to print the AST. What’s needed for the YAXX project was to create an XSLT
spreadsheet
that reads in a “dictionary” of action names, then use the condition to filter
out those tags, in
less than 20 lines of code.
But maybe supporting it natively on Bison generated template is better. Before
deciding on this
effort, do you want to take a look at the yaxx branch below as a starting
point.
http://git.savannah.gnu.org/cgit/bison.git/log/?h=yaxx
Cheers — Yijun
> On 9 Dec 2018, at 06:47, Frank Heckenbach wrote:
>
> Askar Safin wrote:
>
>> Hi. Often the only thing I want to do in Bison is just generate
>> AST and nothing else. Unfortunately, in this case code becomes
>> very repetitive. For example, this is Bison input I used to
>> generate AST for small JavaScript subset:
>> https://zerobin.net/?b9af68c9aa7a31a9#JB4wZseYTq9aKfZOwwZrDqBNCqlEZRj/+DM9bKdgtKU=
>> . Please, support some feature, which eliminates the need to write
>> such repetitive code. Such code can be easily generated from
>> grammar alone
>
> Indeed, I had discussed something similar with Akim Demaille
> privately some time ago; he also mentioned it on this list a few
> weeks ago (I guess I'm one of the "some people" he refers to, but
> unfortunately I was too busy then to get involved):
>
> : Having a means to ask Bison to generate actions given some form of
> : a generic pattern is a different topic. It makes a lot of sense,
> : and some people have discussed about this on various occasions
> : here. That would help to bind to some abstract factory for ASTs
> : for instance, without forcing a specific AST format.
>
> So let me restate and expand upon my suggestion here, which is,
> of course, just a rough sketch. This refers mainly to the C++ output
> as it makes heavy use of templates and overloading. Maybe something
> similar can be done in Java etc., but I'll leave that to the
> respective experts. In C, I think this will only work in a less
> general way which requires more effort by the end-user.
>
> Actually, this would not only mostly automatically generate actions
> to generate ASTs and the like, but also some normal actions in my
> current grammars that don't primarily build ASTs, but contain
> actions that build "mini sub-ASTs", i.e. structures that are later
> acted upon in other actions, e.g. parameter lists while parsing a
> function declaration or call. I guess such actions might be common
> in many grammars.
>
> AFAIK, Bison's current behaviour applied to any rule can be summed
> up like this (I hope I'm not missing important details):
>
> 1. If a user-specified action is given, output this action and
> nothing else; otherwise:
>
> 2. if $$ has no declared type, do nothing; otherwise:
>
> 3. if there are no RHS symbols, default-initialize $$ (when Bison
> knows how to, esp. when using variants); otherwise:
>
> 4. output the default action "$$ = $1;" (possibly with auto-move),
> warning if the declared types of $$ and types are different
> (which may still result in a successful compilation if the types
> are compatible, or a compiler-error down the line if not).
>
> As a side note, though I suggest to introduce this default action
> into C++, I'm not sure if it's actually useful to apply it (in
> any language) when there's more than one RHS argument (or at
> least, more than ne typed one, more about this below). But if
> that's required by POSIX, we'd have no choice, at least in C.
>
> My suggestion is basically to insert another step (optional, of
> course) to auto-generate actions just based on the types involved
> before 3., or even before 2. -- the latter could be useful to
> generate actions that consume parsed data (e.g. to compile a
> function or to store a declaration in an interpreter) rather than
> build structures such as ASTs, e.g.:
>
> 1.5: if an auto-action for the types of $$ and $n can be generated,
> do so; otherwise: ...
>
> So how can such an auto-action be specified?
> A rather general way may use a form similar to %printer, e.g.:
>
> %auto-action { build_foo ($$, $^); } ;
>
> Then any rule where $$ is of type foo and which has no explicit
>
