On Thu, 2002-08-29 at 08:05, Ken Fox wrote:
> A question: Do rules matched in a { code } block set backtrack points for
> the outer rule? For example, are these rules equivalent?
>
> rule expr1 {
> <term> { /@operators/ or fail } <term>
> }
>
> rule expr2 {
> <term> @operators <term>
> }
>
> And a comment: It would be nice to have procedural control over back-
> tracking so that { code } can fail, succeed (not fail), or succeed and
> commit. Right now we can follow { code } with ::, :::, etc. but that does
> not allow much control. I'm a little afraid of what happens in an LL(Inf)
> grammar if backtracking states aren't aggressively pruned.
Well, if /.../ is returning a result object (Let's say
CORE::RX::Result), then I would imagine it's an easy enough thing to let
you create your own, or return the one from a rule that you invoke.
e.g.:
rule { <term> { /@operators/.commit(1) or fail } <term> }
The hypothetical commit() method being one that would take a number and
modify the result object so that it commits as if you had used that many
colons.
{} inside a rule would, I imagine be implemented like so:
sub rxbraces ($code) {
my $stat = $code();
if $stat.isa(CORE::RX::Result) {
return $stat;
} else {
my $r is CORE::RX::Result;
$r.success($stat); # Boolean status-setting method
return $r;
}
}
Or the moral equiv.... In other words, it should be able to return a
result of your choosing.
Sorry if I've missed some of the design. My Perl 6 pseudo-code may not
be legal.
