From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-12 13:05:01
On Monday 11 June 2001 21:57, you wrote:
> 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.
> -Joel de Guzman
This seems reasonable to me. I see no reason why undefined nonterminals could
be a problem (theoretically or practically).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk