Re: [Spirit-general] Conditional parsing and epsilon_p

[Joel de G. <dj...@gm...>]

----- Original Message ----- 
From: "Martin Wille" <mw...@ya...>


> Hi,
> 
> please, consider these snippets:
> 
> oct_or_dec = if_p(ch_p('0')[oct_p].else_p[uint_p]);
> 
> hex_or_dec = if_p(str_p("0x")[hex_p].else_p[uint_p]);

You meant:

    oct_or_dec = if_p(ch_p('0'))[oct_p].else_p[uint_p];
    hex_or_dec = if_p(str_p("0x"))[hex_p].else_p[uint_p];

Right?

[snip

> Also, the default behaviour of condition evaluation for the
> dynamic parsers should be changed to consume the input then.

I was too busy to notice this. I always knew that this was
the correct behavior in the first place. At first I thought we do 
not need a new directive and that the epsilon as it is can do 
what you want: evaluate a parser p without consuming the input.
For example, we can match everything except p without moving 
the scanner:

      eps_p - p    

Yet, I can't find a corresponding production for matching p without
moving the cursor. The closest is:

    eps_p & p

But this fails if the left and right operands have different lengths.
So unless someone comes up with a formula, I think your proposal
makes sense. In fact, in terms of performance, your proposal
should be faster than the eps_p - p idiom.

> On a second thought I realised that epsilon_d isn't a real
> directive since it must not be applied recursively to a
> composite parser.
> 
> Therefore I propose to extend epsilon_p in a way that makes
> epsilon_p not only a standalone parser but also a parser
> constructor that creates an empty-or-no-match parser from
> any parser.
>
> A third thought is that epsilon_p could even be extended to
> construct an empty-or-no-match parser from any bool functor.
> This would allow to omit if_p in cases where there is no else_p
> part: epsilon_p(cond-ftor) >> some_parser. This syntax looks
> quite nice to me. (dynamic parsers should continue to accept
> ftors as parameters.)

Nice. I do not have a strong opinion for or against it being
a directive of a parser. Given two alternatives, I'd choose the
one which is more consistent with what we have already. In
this case, both are ok, IMO.

I think what's more important is the ability to negate the result.
I might suggest:

    ~eps_d[p] or ~eps_p(p)

which is equivalent to 

    eps_p - p

> Opinions?
> 
> Regards,
> m
> 
> PS: The proposed change would have some impact on the implementation
>      of condition evaluation for dynamic parsers and on the
>      implementation of while_p. But I think we gain a lot by the
>      change.

Agreed. I think your ideas and contributions are way cool. In fact,
we really need these features. What's I find really cool is that 
you just discovered Spirit-style semantic and syntactic predicates
through the eps_p that takes in functors and parsers!

Cheers,
Joel de Guzman
jo...@bo...
http://www.boost-consulting.com