On Wed, Sep 05, 2007 at 09:36:24PM -0500, Jonathan Scott Duff wrote:
> How do C<&> and C<&&> differ with respect to backtracking? For instance,
>
> "foobar" ~~ / <[a..z]>+ & [ ... ] /;
>
> Both sides of the C<&> happen in parallel, so I would guess that they
> both match "foo" then stop. Please correct me if that's wrong.
I think the phrase "happen in parallel" overstates things a bit
here. From S05:
The & form is considered declarative rather than procedural;
it allows the compiler and/or the run-time system to decide
which parts to evaluate first, and it is erroneous to assume
either order happens consistently. The && form guarantees
left-to-right order, and backtracking makes the right argument
vary faster than the left.
So, to answer your original question, I think the most we can
say is that C<&&> guarantees a specific order of evaluation,
while C<&> allows the pattern matcher to choose an ordering.
> Were we using the procedural conjunction:
>
> "foobar" ~~ / <[a..z]>+ && [ ... ] /;
>
> I would guess that the LHS matches as much as it can ("foobar"), then
> the RHS matches "foo" [...and then backtracks the LHS until a
> conjunctional match is found...]
>
> Or it's much simpler than that and both of the regexes above just fail
> because of the greediness of C<+> and there is no intra-conjunction
> backtracking.
I think we definitely allow intra-conjunction backtracking.
PGE implements it that way.
On a somewhat similar question, what happens with a pattern
such as
"foobar" ~~ / foo.+? | fooba /
The LHS initially matches "foob", but with backtracking could
eventually match "foobar". Do the longest-token semantics
in this case cause the RHS to be dispatched first, even
though the token declaration of the LHS _could_ match a
longer token prefix?
Thanks,
Pm
