Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk