Re: [boost] Re: Automata builder -- interface

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-05-30 14:52:30

On Wednesday 30 May 2001 02:55 pm, you wrote:
[snip a bunch of text]
> > to be able to, for instance, turn on/off extensions to a language at the
> > parser level, e.g.,
> >
> > if (allow_typeof) {
> >   typespec = TYPEOF '(' expr ')' | TYPEOF '(' type_id ')';
> > }
> >
> > if (allow_template_typedefs) {
> >   type_decl = template_header typedef;
> > }
> >
> > That way one could have a very pure grammar for strict conformance to a
> > language and not worry so much about having extensions break the grammar
> > while running in a mode that does not allow the extensions at all. Why
>
> bother
>
> > to flag an error on use of extensions in the semantic actions if they
> > shouldn't be in the grammar at all?
> >
> > Doug
>
> Pardon my limited imagination but how does this relate to
> the redefinition of rules as exemplified?

We probably shouldn't use the word "redefinition" because it isn't redefining 
but instead adding new productions. Say we have some small language that just 
has variables, numbers, and functions with zero or more arguments enclosed in 
parentheses:

term = VARIABLE 
         | NUMBER
         | FUNCTION '(' *term ')'
         ;

Now after two years of bickering we've standardized this language "X". But 
life moves on and in our "X" compiler we want to add infix addition 
represented by the following production:

term = term '+' term; // call this production PLUS

However, when we are strict standard-compliant mode, infix plus isn't 
available and using it should cause a syntax error. With most parser 
generator tools the author is forced to add a check in the semantic action 
for production PLUS to see if the compiler is in strict standard-compliant 
mode.  Essentially, the production PLUS is invalid when the compiler is in 
strict mode because infix addition isn't supported by the standard. However, 
the production PLUS gets stuck in there because it might get used, and the 
compiler writer is forced to check for errors in the semantic actions to 
alert the user.

What I'm proposing is that we use on-the-fly parser generation to make the 
compiler writer's job easier. The grammar creation portion might consist of:

  Rule<> term;
  term = VARIABLE 
           | NUMBER
           | FUNCTION '(' *term ')'
           ;

  if (!strict_standards_conforming_mode) {
    term = term '+' term; 
  }

Then when the compiler is in strict standard-conforming mode, the grammar 
only contains those productions allowed by the standard. If extensions are 
enabled, the productions are in the grammar. This determination is made at 
runtime so it is suitable for a command-line switch.

> Nevertheless, I wasn't quite accurate. There's no runtime
> penalty. But there sure is code-size penalty even if you
> don't use the feature.
>
> Joel de Guzman

I (obviously) think it's worth the penalty, but more input is nearly always a 
Good Thing.

        Doug