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.
> > 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
> > > 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 :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk