Front page | perl.perl5.porters |
Postings from July 2001
On 2001.07.27 17:14 Jeff 'japhy/Marillion' Pinyan wrote:
> This is forwarded from a conversation I had with Jeff Friedl.
>
> ==========================================================================
> Jeff 'japhy/Marillion' Pinyan <jeffp@crusoe.net> wrote:
>
> |> The only problem is (understandable) that $&, while updated in a
> |> look-ahead, is NOT "down"dated in a look-behind:
> |>
> |> "japhy" =~ m{
> |> ..
> |> (?{ print "<$`><$&><$'>" })
> |> (?=
> |> ..
> |> (?{ print "<$`><$&><$'>" })
> |> )
> |> (?<=
> |> ..
> |> (?{ print "<$`><$&><$'>" })
> |> )
> |> (?{ print "<$`><$&><$'>" })
> |> }x;
> |>
> |> The output is:
> |>
> |> <><ja><phy>
> |> <><japh><y>
> |> <><ja><phy>
> |> <><ja><phy>
>
> The 2nd one looks like a bug to me. The lookahead is just that, lookahead,
> and so I feel that it should never (ever) be part of $&. The other ones
> seem as I would expect them.
> ==========================================================================
>
> I said it didn't seem like a bug, because:
>
> 1. look-ahead is a regex, and the modifications done to $& are localized
So $&, inside the regexp, is the value being constructed :
#!/opt/perl/bin/perl5.7.2 -l
"abc" =~ m{
(?:
. (?{ print "<$`><$&><$'>" })
){3}
}x;
outputs :
<><a><bc>
<><ab><c>
<><abc><>
Shouldn't this be documented in perlre or perlvar?
> 2. if $& wasn't touched, there'd be little to no information you could
> get out of it, apart from capturing (which then bumps up your
> following captures)
Note that capturing would give "ja" and "ph", not "japh".
> 3. look-behind isn't much of a "regex", and so I don't think it gets
> treated the same way internally
You've said it : internally. If you specify what value $& should have
inside an assertion, you make an assumption how the regexp engine is
implemented, or (in other words) you put a constraint on the implementation
of this engine. For example, $& could have been "ph" instead of "japh" if
the assertion was verified by another instance of the engine. That's why I
agree with Jeff Friedl: it seems that his point of view will make it easier
to plug alternate regexp engines or to modify the default one. -- Or,
alternatively, you could say that the value of $& in assertions is
implementation-dependent.
Thread Previous