in reply to Re: Re(6): nested pattern matching
in thread nested pattern matching
The neat new features. I forgot about them, it's been a while since I read the book. Here is the explanation:
First thing, the (?{print "matched at [<$&>] $-[0]\n" }) part is evaluated each time the RegEx engine hits it.
Secondly, The RegEx engine goes from the front to the back, thus matching your search string first. When it is matched, the print part is executed which gives you the data.
Thirdly, there is a negative look-behind assertation afterwards which contains nothing. An empty RegEx matches in any case, and since it is negative this one matches in no case. So, after the print, the RegEx does not match.
The RegEx engine just does not give up here. It tries all the other possibilities and prints those for which the first part matches, but it is always thrown back by the match-nothing part afterwards. I personally thinks that Friedl explains this really well, now that you read this, you might remember some of it.
So, in the end, the RegEx did not match at all while the first part - the important part for you - looped through all possibilities.
In your case, as you probably know, you would just have to substitute the (?{print "matched at [<$&>] $-[0]\n" }) with (?{print "$-[0], " . length($1). "\n" }) and everything works just fine. The solution is really elegant (I should remember to look into that book again).
Some concluding notes: The /x tag allows spaces and comments, which is pretty useless here, since we don't have any. And the question mark in the {3}? is useless as well, because there is no greedy/no-greedy behaviour in a fixed-width assertation.
I hope that the above explained your RegEx a bit.