Re: [RFC] %language declaration

[Tim Van Holder]

Paolo Bonzini wrote:
> Paolo Bonzini wrote:
>> Hi everybody,
>>
>> I plan to implement a Java skeleton for bison; since (if I have time
>> -- I don't guarantee anything on this part) I would also like to
>> implement GLR parsing for Java, the attached patch attempts to provide
>> a "%language" declaration that wraps over "%skeleton".
>>
>> Together with %language, there is a -L option to determine the
>> language from the command-line.
>>
>> -L and -S are mutually exclusive, as are %language and %skeleton, but
>> the command-line options override the grammar directives.
>>
>> Would something similar, of course with documentation and against
>> mainline rather than 2.0, be ok to apply?  The copyright process is in
>> the works.
>>
> The now attached patch...
> 
> Paolo

I like the idea.

> diff -rNu --exclude=ppp bison-2.0-orig/src/output.c bison-2.0/src/output.c
> --- bison-2.0-orig/src/output.c       2004-12-17 20:56:45.000000000 +0100
> +++ bison-2.0/src/output.c    2006-09-11 10:27:53.000000000 +0200
> @@ -614,9 +614,14 @@
>    if (!skeleton)
>      {
>        if (glr_parser || nondeterministic_parser)
> -     skeleton = "glr.c";
> +     {
> +       skeleton = language->glr_skeleton;
> +       if (!skeleton)
> +         error (EXIT_FAILURE, 0,
> +                _("GLR parsing not supported for the selected language"));
> +     }
>        else
> -     skeleton = "yacc.c";
> +     skeleton = language->lalr1_skeleton;
>      }
>  
>    /* Parse the skeleton file and output the needed parsers.  */

Maybe test the "else" also - in case someone contributes, say, a GLR C#
skeleton but not a C# LALR(1) skeleton.

In fact, since the mechanism is mainly supposed to simplify skeleton
selection, why not have a tuple like (language, grammartype, skeleton)?
This would make it quite easy to add new grammar/parser types to bison.
Even with current bison capabilities, does %nondeterministic-parser
always mean the GLR skeleton should be used (for any language)?  Given
that glr_parser is a separate flag, I assume this is not the case.
As such, perhaps the current %xxx-parser directives could then become
aliases for "%parser-type xxx" (or "%grammar-type xxx", whichever is
more appropriate).