|
in reply to Re: Pattern matching with qr// and modifiers
in thread Pattern matching with qr// and modifiers
Thanks to jwkrahn for the reply.
Ok, perl 5.10.1 gives me: (?-xism:fox.+?jumps).
Under perl 5.14.2 I get: (?^:fox.+?jumps). In perlre: Extended Patterns, this is explained as follows:
Starting in Perl 5.14, a "^" (caret or circumflex accent) immediately after the "?" is a shorthand equivalent to d-imsx.... The caret tells Perl that this cluster doesn't inherit the flags of any surrounding pattern, but uses the system defaults (d-imsx), modified by any flags specified.
So, in both cases qr// compiles $regex with the 's' modifier turned off.
I find it surprising that adding the modifier back later has no effect, and triggers no warnings. I guess I’ll just have to remember that once a regex has been compiled with qr//, its d, i, m, s, and x settings are thereafter immutable.
By the way, perlop: Regexp Quote Like Operators says of qr//:
This operator quotes (and possibly compiles) its STRING as a regular expression.
Why “and possibly compiles”? Under what circumstances does qr// quote rather than compile, and what difference would this make?
Thanks,
Athanasius <°(((>< contra mundum
|
Re^3: Pattern matching with qr// and modifiers
by JavaFan (Canon) on May 05, 2012 at 09:47 UTC
|
I find it surprising that adding the modifier back later has no effect, and triggers no warnings. I guess I’ll just have to remember that once a regex has been compiled with qr//, its d, i, m, s, and x settings are thereafter immutable.
Well, isn't that the point of having a compiled regexp? Now, if you compile a regexp, you know exactly what you have. Otherwise, if I have a compiled regexp, I still don't know what it does, because modifiers can be applied. It also means that if you would do something like:
my $pat = gimme_pat(); # Some method returning a qr
if ($str =~ /^ $pat $ # Anchor pattern/x) {
...
}
will break if $pat uses spaces. | [reply]
[d/l]
[select] |
|
|
Yes, this makes sense; but that “quotes (and possibly compiles)” in perlop is still worrying me. If I use qr// but it only quotes (and doesn’t compile), then, as you say, I still don’t really know what it does, do I?
Thanks,
Athanasius <°(((>< contra mundum
| [reply] |
Re^3: Pattern matching with qr// and modifiers
by sauoq (Abbot) on May 05, 2012 at 12:37 UTC
|
I find it surprising that adding the modifier back later has no effect, and triggers no warnings.
It does have an effect. The effect is on the pattern you add it to though, not on the compiled pattern. The following illustrates what I mean:
$ perl -le '$r = qr/qux./; $s = "qux\n"; print "matches" if $s =~ /$r/
+'
$ perl -le '$r = qr/qux./; $s = "quxxx"; print "matches" if $s =~ /$r.
+/'
matches
$ perl -le '$r = qr/qux./; $s = "quxx\n"; print "matches" if $s =~ /$r
+./'
$ perl -le '$r = qr/qux./; $s = "quxx\n"; print "matches" if $s =~ /$r
+./s'
matches
-sauoq
"My two cents aren't worth a dime.";
| [reply]
[d/l] |
Re^3: Pattern matching with qr// and modifiers
by AnomalousMonk (Archbishop) on May 05, 2012 at 19:29 UTC
|
I guess I’ll just have to remember that once a regex has been compiled with qr//, its d, i, m, s, and x settings are thereafter immutable.
But this is not unusual. To my mind, it is similar to having to remember that the function
sub func { my $x = 42; return $x; }
will always return 42 regardless of any value assigned to any global or lexical $x scalar in any calling scope of the function. The return value of the function is, in a sense, 'immutable' — unless, of course, the function returns a reference to the lexical, which is a whole 'nother ballgame; but regex modifiers have no truck with such referential semantics. In other words, it is purely a scoping question.
Why “and possibly compiles”? Under what circumstances does qr// quote rather than compile, and what difference would this make?
In the discussion of qr// in the Regexp Quote Like Operators section of perlop, see the paragraphs beginning "Since Perl may compile the pattern..." and "Precompilation of the pattern into an internal representation..." for some light on this question.
As I understand it, a regex object has both an internal representation (for use by the interpreter at run time) and a 'stringized' representation (for the convenience of the programmer, and for interpolation in strings and other regex objects at compile time), along with a bunch of rules for converting between the two. In the example given in perlop, the qr/$_/i sub-expression in the
my @compiled = map qr/$_/i, @$patterns;
statement cannot possibly be referred to in its stringized form because no 'hard' or 'soft' reference to it is created; it can therefore be compiled directly to an internal representation.
Similarly, the number 1.2345 has both an internal (IEEE 754, 64-bit) representation (actually, an approximation; see What Every Computer Scientist Should Know About Floating-Point Arithmetic) and a stringized representation (e.g., '1.2345'); if the number is used purely as a number and never printed, it may never exist in its stringized form, but only as its internal representation.
| [reply]
[d/l]
[select] |
|
|
