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?  



Reply via email to