Re: [boost] Formal Review: The Spirit Parser Framework.

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-10-12 21:48:12

----- Original Message ----- 
From: "Dan Gohman" <dgohman_at_[hidden]>

> On Sat, Oct 12, 2002 at 03:12:44PM +0200, Martin Wille wrote:
> > The problem with this is that
> > 
> >   r |= a;
> > 
> > would not be equivalent to
> > 
> >   r = r | a;
> 
> Actually, I meant to suggest this new operator|= be in addition to
> the existing operator=, in which case the above two would be equivalant.
> I think the operator|= would be more natural for writing traditional
> EBNF code, though.

I'm sorry to disappoint you guys but r = r | a; is a classic case of left recursion
and in top-down parsing will result in an infinite loop...

Perhaps what you really wanted was:

    r = previous_definition_of_r | a;

declarative EBNF has no such "imperative" notion. Yet, what Martin is
stating is that while this is possible to achieve in Spirit, the behavior
of:

    r = r | a; // left recursion

will be different from

    r |= a; // previous_definition_of_r | a;

Which will surely be a source of confusion.

Also, further down the road, since Spirit also supports

a | b... union (alternative)
a - b... difference
a & b... intersection
a ^ b... exclusive or

Then supporting |= will also mean supporting -=, &= and ^=. Now let's see...

r = r | a;  
r = r - b; 
r = r & b; 
r = r ^ b; 

All the cases above are left recursive. 

In conclusion, I think what should be done instead is to focus on
a way to solve the r.alias() nuisance. Admittedly, I don't like it
either. When Spirit v1.5 changed the behavior of the rules
to be copyable and storable in containers, I remember I had
an unpleasant time trying to track the problem in the Pascal
parser where there are lots of rules such as:

    indexType  =  simpleType;

, where simpleType is not yet defined.

...The pains of marrying declarative EBNF with imperative C++!

A solution I have in mind is make the rule class accept a
bool template parameter ... bool copyable = false>. When one
needs to deal with dynamic parsing which will involve the 
manipulation of rules, placing them in stacks, maps, vectors etc.,
then she can set it to true. All the rest will be happy with this
set to false as default.

Thoughts?

--Joel