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

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-10-20 18:40:26

----- Original Message -----
From: "Juan Carlos Arevalo-Baeza" <jcab.lists_at_[hidden]>

>    Also note that, with the typeof extension (or actually researching the complete type, but
that's painful), the skipper_error_parser is not needed:
>
> template < typename ParserT, typename SkipperT >
> typeof(cpp_guard(parser)[skip_error_handler(skipper)])
> error_skipper_p(ParserT const& parser_, SkipperT const& skipper_)
> {
>     return cpp_guard(parser)[skip_error_handler(skipper)];
> }
>
>    How's that for another reason to keep it? Or even to provide a mechanism, similar to the
proposed "auto" extension, to eliminate the redundancy? I'd propose something like macro functions:
>
> template < typename ParserT, typename SkipperT >
> auto error_skipper_p(ParserT const& parser_, SkipperT const& skipper_)
>     = cpp_guard(parser)[skip_error_handler(skipper)];
>
>    But I digress...

Since you started it.... The auto and typeof keyword will extremely simplify
the Spirit framework. I imagine a 30..40 % reduction in terms of number of
lines of code.... (And Phoenix/Lambda for that matter).

....no more return type computers...

Also, rules will be obsolete. Consider:

    fwd_rule<1> expression;

    auto group  = '(' >> expression >> ')';
    auto factor = integer | group;
    auto term   = factor >> *(('*' >> factor) | ('/' >> factor));
    auto start  = expression = term >> *(('+' >> term) | ('-' >> term));

... no more scanner/rule business ...

The implication of this is immense. A fully static
"auto" rule will allow aggressive metaprogramming.

--Joel