Re: RFC 72 (v2) The regexp engine should go backward as well as forward.

I've been lurking a few days now, and RFC 72 piqued my interest.  I see the
motivation for a backwards-moving regexp engine, but am uncomfortable with
the details.

First worry is the syntax proposed.  I cringe when I see the regexp being
expressed such that "(?r)EDCB" matches "BCDE".  That and the jumping between
the left-end of the match and the right-end of the match make for a
near-unreadable regexp.

> As a frivolous illustration, the string
> ABCDEFGHIJKLM
> would be matched by:
>     m/FG(?r)EDCB(?f)HIJK(?r)A^(?f)LM$/

Can this be repackaged in such a way that it is a more natural extension of
the existing regexp language?

The RFC notes that the look-behind construct (?<= pattern) can almost be
used.  Two issues:  1. as currently implemented, the pattern must be of
fixed length.  2. this is a zero-width assertion.

Speculation says the fixed length limitation was done because it offered a
relatively quick hack.  A fixed length pattern allows you to go back in the
matched-against string that many characters and match the pattern forwards.
If the regexp engine could "go backwards", then the fixed-length restriction
would be lifted.

The zero-width assertion might be an issue.  The RFC's example doesn't
really get into this.

> Imagine a very long input string containing data such as this:
>     ... GCAAGAATTGAACTGTAG ...
> If you want to match text that includes the string GAAC, but only when it
> follows GAATT or any one of a large number of other different
possibilities,

If it important to be able to do both:

  $large = join '|', @possible'
  $data =~ / (?<= $large) GAAC /x;   # Don't care which @possible?

and

  $data =~ m/ ($large) GAAC /x;   # Need $1 to say which @possible

Then perhaps a back-reference-setting look-behind could be implemented?
Don't have an obvious syntax to use (back-tick == back-reference?), but
something like:

  $data =~ m/ (?`<= $large) GAAC /x;   # Need $1 to say which @possible


Does this ehanced look-behind satisfy the RFC's needs?

  = mike "looking for a sig" mulligan