in reply to The "anchor" misnomer in regexes

But the regex /\s+$/ is not anchored (and this grieves me). I've used this example time and time again when explaining regex reversal and that whole tangent, and it's useful again. If the regex were really anchored (that is, immovable), it would find the end of the string, and then match the regex in that context -- that is, the regex would have to terminate at the end of the string. As it stands, Perl can't optimize the regex that way, and we end up matching EVERY chunk of whitespace, and then testing to see if END-OF-STRING comes after it.

I think its important to remember this point only applies to \z (and maybe, I think, \Z) and where $ is the same as \z.

The logic makes sense when $ is actually end of line and not end of string, as it means doing a scan through the string to find the newline, which means it might as well keep track of state as it goes so it knows where the spaces start.

I guess what is a pity is that there isn't an optimization that handles this as a special case. It seems to me that patterns of this type could be special cased somehow. (And I mean this in the general case of /CLASS QUANTIFIER EOS/ and not just /\s+$/)

---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re^2: The "anchor" misnomer in regexes
by Aristotle (Chancellor) on Dec 26, 2005 at 05:59 UTC

    I’m not sure you have the semantics all correct: \z is always “end of string” and nothing else. \Z and $ are identical by default and mean “end of string, but before a newline if that’s the last character.” However, if you use the /m regex modifier, then $ (but not \Z) changes to line-based semantics and essentially says “before the next newline or at the end of the string (whichever is first).”

    Just to straighten things for anyone for whom they were unclear.

    (The clarification does, of course, not affect what you said about keeping state for $.)

    Makeshifts last the longest.

[reply]
[d/l]
[select]
      Additional clarification, just to muddle things a little:
      However, if you use the /m regex modifier, then $ (but not \Z) changes to line-based semantics and essentially says “before the next newline or at the end of the string (whichever is first).”
      The choice isn't next newline or end of string and isn't whichever is first; regular leftmost/longest backtracking rules apply. So this: 
      ("\n" x 10) =~ /(\s+?$)\s{3}\z/m;
print length $1;

      [download]
      gives 7, with the $ matching before the third-to-last newline. Same results without the ?.
[reply]
[d/l]

        What are you proving? The \s+ part will start as far on the left as it can, and since your string is all newlines and you’re always using \s when you ask for character matches and have turned on /m, all character matches can match anywhere and the $ can match between any characters. So you’re not actually saying anything. No part of your pattern is constrained in any way, given the data you’re running it against.

        I guess the bit I wrote about firstness does not actually say anything either, since “whichever is first” means “whichever is left-most” anyway and at any location between characters, only one of these conditions can be true. So $ in multiline mode matches before any newline or before the end of the string, and that’s that.

        Makeshifts last the longest.

[reply]
[d/l]
[select]

In Section Meditations