NAME

Regexp::DeferredExecution - Defer execution of (?{}) codeblocks until the end of a successful match

SYNOPSIS

  use Regexp::DeferredExecution;
  "foobar" =~
    /(?:foo (?{ warn "matched foo!" }) ) d
     |
     (?:bar (?{ warn "matched bar!"}) )
    /x;

  __END__
  matched bar!

DESCRIPTION

The Perl regular expression engine provides a special embedded pattern, (?{ <code> }), that immediately executes <code> if and when the pattern is used during the matching process. In the SYNOPSIS example, the initial foo subpattern is initially matched by the regular expression engine, and the associated code would normally be executed immediately, even though the final successful match does not include the foo subpattern nor it's associated code. Sometimes, that's not the desired behavior.

Regexp::DeferredExecution overrides the qr function such that all of the code blocks get deferred until the very end of the match, at which time only the blocks participating in the overall successful match are executed. That doesn't sound like much, but it does allow you to change this:

  if(m/ (fee) .* (fie) .* (foe) .* (fum) /x) {
      ($fee, $fie, $foe, $fum) = ($1, $2, $3, $4);
  }

into:

  use Regexp::DeferredExecution;
  m/ (fee) (?{ $fee = $^N }) .*
     (fie) (?{ $fie = $^N }) .*
     (foe) (?{ $foe = $^N }) .*
     (fum) (?{ $fum = $^N })
   /x;

Which means that adding new sets of capturing parentheses doesn't require the counting exercise to figure out which set is $1, $2, etc.

Of course this mechanism isn't specific to code that makes assignments from $^N; there's no doubt a bunch of other clever things you can do with this as well. I'll let you know as I run into them.

There's also an article describing the issues with (?{}) at perl.com:

  http://www.perl.com/pub/a/2004/01/16/regexps.html

USAGE

Like any other package that overloads core functionality, you can turn it on and off via "use" and "no" statements.

BUGS

Note that only the currently active $^N matching variable is kept for delayed access (e.g. don't try to access other special regexp variables from within a (?{}) code block, because they might not be as you'd expect). Not really a bug, just a lack of features.

None so far, but it's still early.

TODO

When closures can be compiled from within (?{}) constructs, all the special variables will become available and this will all be much simpler.

AUTHOR

Aaron J. Mackey <amackey@virginia.edu>

SEE ALSO

perlre, Regexp::Fields, Regexp::English