Boost logo

Boost :

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-12 13:05:01


On Monday 11 June 2001 21:57, you wrote:
> Hi,
>
> Some BNF variants allow:
>
> r ::= a
> r ::= b
>
> Which is equivalent to:
>
> r ::= a | b
>
> Douglas Gregor noted that allowing the addition of new
> productions would be extremely useful to be able to, for
> instance, turn on/off extensions to a language at the parser
> level. Example:
>
> if (allow_typeof)
> typespec = TYPEOF >> '(' >> expr >> ')'
>
> | TYPEOF >> '(' >> type_id >> ')';
>
> if (allow_template_typedefs)
> type_decl = template_header typedef;
>
> Essentially, the declarative nature of (E)BNF productions
> when inlined with imperative C++ statements yield an
> uncanny mix. The C++ assignment operator substituting
> as BNF's ::= operator when applied to the addition of
> new productions might cause confusion.
>
> The |= operator, as suggested by George Heintzelman,
> may used for this purpose. Yet, this too might cause
> confusion as one might expect &=, -= and ^= to be
> equally applicable.
>
> Also, after some deliberation, both cases impose runtime
> and code size penalty. Thus, I've come up with a very
> simple solution:
>
> Undefined Rules:
>
> An undefined rule matches nothing. This can be used to
> turn on/off extensions to a language at the parser level.
> For example:
>
> r = feature_a | feature_b;
> if (allow_feature_b)
> feature_b = /*...define feature_b...*/;
>
> If the flag allow_feature_b is false, feature_b will be left
> undefined and will match nothing when parsing proceeds.
> So, the rule r will only have only one alternative.
>
> Comments?
> -Joel de Guzman

This seems reasonable to me. I see no reason why undefined nonterminals could
be a problem (theoretically or practically).

Good solution.

        Doug


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