C++ LALR(1) skeleton

[Hans Aberg]

[I am currently not on this list, so replies, please cc me.]

I submit my own C++ LALR(1) skeleton file, not for final inclusion in
Bison, but so that if somebody wants to work on the problem of making an OK
C++ skeleton file can do it.

The skeleton file expects a Bison tweak:

In file reader.c,  prologue_augment(), change from
  struct obstack *oout =
    !typed ? &pre_prologue_obstack : &post_prologue_obstack;
to
  struct obstack *oout =
   (!typed && !prologue_count++) ?
     &pre_prologue_obstack : &post_prologue_obstack;

Currently Bison works so that one can only have two different %{...%}
initial segments, called the pre-prologue and post-prologue, in the .y file
if %union is invoked. However, under C++, %union does not work with C++
types having nontrivial constructors, as it is implemented using a C/C++
"union" which does not admit that.

The tweak above merely makes it possible to have the pre-prologue and
post-prologue code segments regardless whether %union has been invoked or
not. I then put the pre-prologue code in the C++ header that Bison writes,
and the post-prologue in the C++ source file.

A better solution would probably be to have a Bison command
  %code <identifier> { <code> }
which would create an M4 macro with a name derived from <identifier>,
expanding to <code>. Then thing is that when working on integrating the
Bison C++ parser with the Flex C++ lexer, there are several more places to
put code: before, in, in between, after the Flex and Bison classes. I do
not know which blend which corresponds best to genuine C++ paradigm
programming; perhaps more than one possibility should be supported.

Also, as the %union feature is useless when using C++ types with nontrivial
constructors, I would want a Bison command %typed that merely sets the
internal variable "typed". Currently, %union sets typed, and that causes
also a union to be written. But under C++, one might use a polymorphic
(virtual) class hierarchy instead. So %union would have to set the variable
typed plus another telling to write a union.

I used such a tweak in Bison for while, but as a type error with a
polymorphic C++ system will cause an exception, which can be detected at
parser runtime, I did in the end not feel that static Bison .y file typing
is so essential. But if one would want such static typing and to be able to
use C++ types with nontrivial constructors in connection with that, then
one must have such a tweak.

lalr_ha1.cc
Description: Text document

  Hans Aberg