%define, %typed and C++ and all that

[Hans Aberg]

I have looked a bit on the experimental %define, and it seems OK, but it
will probably be cumbersome to enter code in the form of strings. One way
around this, towards better usability, is to allow more than one input
format for these strings. Specifically, one might make so that:
  a. Input without delimiters uses the usual C/C++ identifier format.
  b. Input within {...} uses a code input format.
  c. Quoted input "..." uses usual C/C++ string format.
One might then write commands like
  %define header_code {...}
  %define parser_code {...}
etc., which seems to be fully acceptable. This provides for quick
development of new code insertion points, as well as providing a reasonable
user interface.

In terms of the parse-gram.y grammar, the %define rule would be someting
like:

declaration:
  ...
  | "%define" string string  { muscle_insert ($2, $3); }
  ...
;
string:
    ID
  | CODE
  | QUOTED_STRING
;
where CODE and QUOTED_STRING is what currently is procced by the STRING toke
(I think).

In addition to this, for experimentation with C++ and Bison's static type
system, in order to go beyond the %union command, which does not admit
classes with non-trivial constructors, I need a new command: %typed. This
command %typed should do nothing but to set
    typed = true;
as to trigger Bison's type system. Its placement, syntactically, should
probably be the same as %union, and one should not be able to use both.

It strikes me that one should perhaps be able to forward diagnostics (info,
warning, error) to Bison from the skeleton file. Instead of using the macros
m4_error, etc, one would then have macros b4_error, etc., that generate
tags, which are then processed by the scan-skel.l lexer in order to produce
the suitable Bison diagnostic message. (I was led to this idea, as on my
system, Bison and M4 errors are treated differently. But perhaps it is of no
importance on a UNIX system.)

And it seems me that the scan-skel.l rule "@output ".*\n should be
simplified, as to not use the @output_header_name@ and @output_parser_name@
names. Instead, just use macros b4_output_header_name and
b4_output_parser_name.

  Hans Aberg