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

On 2 June 2010 13:52, Abigail <[email protected]> wrote:
> 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.

Yeah, thats what i meant when i said "its already compiled so it makes
sense to treat it a distinct object". The wrapping in a (?:..) is
basically only needed because we /do/ actually concatenate at the
regex engine level, and we want to simulate the "this is already
compiled" behaviour that one expects.

Basically Dave M's suggestion involves treating a qr// object
something like how we currently treat it when its wrapped in (??{...})
construct, except that the capture buffers would be somehow shared.
(iirc). For instance we could treat the compiled program as a
relocatable library, and just remap the capture buffer indexes and not
even compile it when embedding.

In that case there would be no cost to embedding a qr// object,
something that I recall you have complained about in the past.

>> 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.

Yeah thats what i mean.

> 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.

Nobody is suggesting removing them. Just recommending other constructs.

TBH, these days I dont think it matters much, as most new devs dont
use octal and instead use hex, and seem to be inclined toward the
\x{...} form as opposed to the \xDF form.

> 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.

Agreed.

Yves



-- 
perl -Mre=debug -e "/just|another|perl|hacker/"