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