Re: What should /\08/ match and do?

[email protected] (Abigail)
Newsgroups perl.perl5.porters
Message-ID <20100602115203.GE12847@almanda>
On Wed, Jun 02, 2010 at 01:24:31PM +0200, demerphq wrote:
> On 2 June 2010 12:22, Nicholas Clark <[email protected]> wrote:
> > On Tue, Jun 01, 2010 at 10:38:10PM +0200, demerphq wrote:
> >> On 1 June 2010 22:30, Abigail <[email protected]> wrote:
> >> > On Tue, Jun 01, 2010 at 11:52:38AM -0600, karl williamson wrote:
> >> > This one is sneaky as well:
> >> >
> >> >    $a = '(.)\1';
> >> >    "aa" =~ /${a}/;      # True
> >> >    "aa0" =~ /${a}0/;    # False!
> >> >    "aa\x8" =~ /${a}0/;  # True!
> >>
> >> Wow. Those are gnarly.  Thats a great example of why using old style
> >> back refs is dangerous. Might even be worth adding to the docs?
> >
> > Or, alternatively, that interpolation is happening too early in regexp
> > compilation, such that it's possible to produce syntactically valid
> > constructions by co-incidence.
> 
> Yeah, i thought that at first too, in reference to comments Dave M
> made years ago in relation to embedding a qr// object in a larger
> pattern.

The concantenation problem does not happen when embedding qr// constructs,
as the stringification of a qr// construct always adds a set of parens.
But you cannot do this with qr:

    my $repeat = foo() ? '\1' : '\2';
    my $pat = qr /(.)(.)$repeat/;

as qr /\1/ and qr /\2/ aren't valid.

> But in terms of /strings/ I don't think it is actually correct. How
> could we tell when its deliberate? People construct complex patterns
> all the time out implicitly concatenated vars wheras a compiled
> pattern is already compiled, so it makes sense to treat it as distinct
> unit.

I certainly have written constructs like:

    my $x = $capturing ? "" : "?:";
    my $pat = qr /...(${x}...).../;

which rely on interpolation before compilation.


I do want to say that while the "concatenation problem" exists, I don't
see it as a huge problem. I cannot recall ever been bitten by it. I don't
recall ever seeing any code written by someone else that suffers from 
this problem. And that while the use of \NNN for backreferences is common
as dirt. Making any change in behaviour is going to upset more people than
it'll save errors.

I'd say that pointing this potential problem out in the docs should
be enough. Perhaps the docs should even use \g{NNN} when introducing
backreferences, mentioning \NNN later on as an older, problematic,
construct. But that still isn't going to rewrite all the books and
other docs out there, nor change the finger memory of experienced coders.



Abigail
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.