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

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

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

> On Sat, Oct 12, 2002 at 08:38:48AM +0800, Joel de Guzman wrote:
> > First of all, thanks!
> 
> Thanks to you and everyone else that has developed Spirit. It
> is a very impressive library.

Thanks.

> > Pre 1.5 Spirit did it that way. Yet, here's the rub: doing so
> > would prevent rules from being storable in containers. Previous
> > experiments with dynamic parsers necessitated rules that are
> > copyable and storable in stacks, vectors etc. 
> 
> Perhaps Spirit should use operator|= for the EBNF syntax. This function
> could then provide behavior whatever semantics desired without having
> to be constrained by the otherwise-unrelated container requirements.
> 
> For example, operator|= could implement the 1.3 behavior:
> 
>   r |= a;
>   r |= b;
> 
> This would be equivalant to `r = a | b' in 1.5 syntax.

I believe this is already answered by Martin.

> When writing in the EBNF-syntax, I don't want to have to worry about
> details like remembering to use .alias() for rules that need it.

Same here. I will try to come up with a better aliasing solution.
FWIW, a warning is printed when one tries to alias a rule that
is undefined. I'd appreciate it a lot if someone can suggest a
better alternative while still maintaining the copyable/assignable
semantics.

> > > Types like anychar_ look like they should be moved into an
> > > implementation-detail namespace.
> > 
> > Why?
> 
> They're not mentioned in the documentation, and as far as I can see, library
> users never need to use these by name; anychar_p and the others are the
> way that library users use these.

It's all my fault. I was really intending to have a full reference.
Unfortunately I was not able to write one with the 1.5 release.
I understand now that the names should be changed to something
like anychar_parser. It is low-level but still part of the API. 
When we get to dynamic parsers and in the interest of 
meta-spirit programming (i.e. expression tree traversal and
transformation), these names will need to be exposed.

Thus, as I mentioned in my other post, in the interest of moving 
forward, I agree to change the names :-)

Many thanks,
--Joel