On 5/4/2010 11:25 AM, Hartmut Kaiser wrote:
On 5/4/2010 4:37 AM, Hartmut Kaiser wrote:
Eric Niebler wrote:
It's an open question whether it's desirable to hide the proto bits when exposing these customization points, and if so, what that would look like.
Even if I'm only remotely connected to this I would like to emphasize the importance of a simple extension interface. By 'simple' I mean: hide Proto! We do not need the full power of Proto here and forcing every user to understand Proto's fine details before he is able to write his own actor is not good. Yes, it is possible to hide Proto completely behind a set of well-crafted domain specific (i.e. Phoenix) interfaces. This has been done already in Spirit (V2) and has proven to work well.
Hartmut, where can I find the documentation for Spirit's extensibility mechanism?
Ahem... There isn't any :-P At least nothing complete. There are bits and pieces described in several places (like here:
http://www.boost.org/doc/libs/1_42_0/libs/spirit/doc/html/spirit/advanced/in...
and here:
http://boost-spirit.com/home/articles/qi-example/creating-your-own-parser-co...),
but nothing coherent yet.
You'll have to resolve to the source code for now, sorry.
That's OK. The extensibility mechanism for Phoenix is documented, and I can make my own inferences. The challenge here will be to preserve the strengths of a Proto-based design (a well-defined grammar against which expressions can validated, and clean separation of data structure and algorithm) with a clean extension mechanism. The Phoenix that we know and love is clean and simple, but conflates data structure and algorithm. That may not be an issue -- I can't think of alternate algorithms for lambdas the way I can for parsers and regex engines. But separation of data structure and algorithm is sound design, and I would think twice before giving it up. I foresee some long Phoenix hack sessions in Aspen next week. -- Eric Niebler BoostPro Computing http://www.boostpro.com