develooper Front page | perl.perl5.porters | Postings from March 2012

Modifiers ignored when qr variable is sole contents of //

Thread Next
From:
Peter Scott
Date:
March 28, 2012 09:50
Subject:
Modifiers ignored when qr variable is sole contents of //
Message ID:
20120328165029.3562.qmail@lists-nntp.develooper.com
I'm not perlbugging this yet because it appears to have come up before in 
http://rt.perl.org/rt3/Ticket/Display.html?id=59368 and rejected, but 
that thread does seem specific to the /m modifier only, so I'm not sure 
that it applies.

If modifiers are applied to a // interpolating a qr variable and there is 
nothing else in the pattern to make it recompile, those modifiers are 
silently ignored.  This seems wrong to me, or at the very least 
incompletely documented and/or counterintuitive.  Why should

qr/$r/i  and  qr/$r$/i

differ in any respect other than the added anchor?  But they do:

$ perl -le '$r = qr/a/; $r1 = qr/$r/i; $r2 = qr/$r$/i; $r3 = qr/(?^i:
$r)/; print for ($r, $r1, $r2, $r3)'
(?^:a)                 # $r = qr/a/
(?^:a)                 # qr/$r/i
(?^i:(?^:a)$)          # qr/$r$/i
(?^:(?^i:(?^:a)))      # qr/(?^i:$r)/

I'd have thought that /$r/i and /(?^i:$r)/ should be equivalent.  As you 
can see, they're not.

I presume this is happening because an optimization says "don't recompile 
if the pattern contains only a qr".  I think this should be changed if 
there are pattern-changing modifiers.

The closest I can find to documentation on this is in Camel III, p.194:

"Now when you run the match, Perl doesn't have to create a compiled 
regular expression on each if test, because it sees that it already has 
one."

But that leaves the effect on modifiers to implication.

-- 
Peter Scott


Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About