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

[Hans Aberg]

On 2005/01/04 11:15, Akim Demaille at address@hidden wrote:

>> In terms of the parse-gram.y grammar, the %define rule would be someting
>> like:
> 
>> declaration:
>> ...
>>> "%define" string string  { muscle_insert ($2, $3); }
> 
> Except for the first string, this is also what I have in mind.

For the first string, I think one might use either the common C/C++
identifier format, or a C/C++ quoted string "...". The first format would
normally suffice, but the latter keeps open for special macro names.

>  But do
> understand that we do not want to carve into stone the interface with
> the skeletons, this is why it has not happened yet.

I think that an unofficial implementation is needed, plus some
experimentation with it, before a more permanent choice can be implemented.
So it should not be a problem to make it now.

>For instance in
> the near future Guile will replace M4 to process the skeletons.

I do not now about Guile. Do you have pointer?

I do not see any point in linking the two issues, though. The stuff above
will be experimental, and can be made permanent more quickly, once you have
switched to Guile.

>> 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.
> 
> More specifically, what would that typed = true involve?

This assignment is the same as in the "%union {...}" action. My memory is
unfortunately somewhat hazy as to what is needed in addition to that (see
below). But the %typed part is what I do not want to implement myself, in
view of that it requires making new lexer and parser files.

I think that the rest could, at the time, be handled by some minor tweaks of
Bison, putting the appropriate typing stuff into suitable macros. Bison
translates $<type_name>k into <something(k, n)>.<type_name>, where n is the
rule length, i.e., a C/C++ union subfield. What I needed was to ensure that
this instead was translated it into <something(k, n, type_name)>, so I could
write the suitable C++ casts (if that now is a static_cats or a dynamic cats
or some other preference). But now, when the stuff already is pout onto
macros, perhaps this part is essentially automatic.

In addition, when using such casts, one has to note (as done in the ToDo
file) that the default rule $$ = $1 needs not agree anymore with the correct
$<type_name>$ = $<type_name>1. If problematic, this needs not be changed
immediately, as in the first experimentation, one can write out all default
rules explicitly.

The stuff above needs to be in place, for some experimentation, before one
can decide which C++ styles to support. I think though that it may not be
sufficient to support a single C++ style. So some generality in
implementation is probably to prefer.

>> 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.
> 
> Paul precisely changed the latter into the former to cope with
> special characters in filename that might break our interface with
> M4.  Again, moving to Guile will certainly free us from this issue.

I did not give thought to special characters, as, by experience, I find it
is wise to avoid them in filenames. So this is not a hot topic to me. If
Guile can handle all postprocessing, without having to have Bison to do some
of it, that is probably a setup to prefer.

  Hans Aberg