7.10 Final Comments

I'm sure it's obvious that I'm quite enamored with Perl's regular expressions, and as I noted at the start of the chapter, it's with good reason. Larry Wall, Perl's creator, apparently let himself be ruled by common sense and the Mother of Invention. Yes, the implementation has its warts, but I still allow myself to enjoy the delicious richness of the regex language and the integration with the rest of Perl.

However, I'm not a blind fanatic—Perl does not offer features that I wish for. Since several of the features I pined for in the first edition of this book were eventually added, I'll go ahead and wish for more here. The most glaring omission offered by other implementations is named capture (see Section 3.4.5.3). This chapter offers a way to mimic them, but with severe restrictions; it would be much nicer if they were built in. Class set operations (see Section 3.4.2.6) would also be very nice to have, even though with some effort, they can already be mimicked with lookaround (see Section 3.4.2.6).

Then there are possessive quantifiers (see Section 3.4.5.10). Perl has atomic grouping, which offers more overall functionality, but still, possessive quantifiers offer a clearer, more elegant solution in some situations. So, I'd like both notations. In fact, I'd also like two related constructs that no flavor currently offers. One is a simple "cut" operator, say \v , which would immediately flush any saved states that currently exist (with this, x+\v would be the same as the possessive x++ or the atomic grouping (?>x+) ). The other related construct I'd like would take the additional step of prohibiting any further bump-alongs by the transmission. It would mean "either a match is found from the current path I'm on, or no match will be allowed, period." Perhaps \V would be a good notation for that.

Somewhat related to my idea for \V , I think that it would be useful to somehow have general hooks into the transmission. This would make it easier to do what we did in Section 7.8.3.

Finally, I as I mentioned in Section 7.8.3, I think it would be nice to have more control over when embedded code can be interpolated into a regex.

Perl is not the ideal regex-wielding language, but it very close, and is always getting better. In fact, as this book is going to print, Larry Wall is forging ahead on the design of Perl 6, including a recently-released paper describing his radical new ideas for the future of regular expressions. It will still be some while before Perl 6 is a reality, but the future certainly looks exciting.

7.11.1 Quiz Answer

Answer to the question in Section 7.6.

The question snippets in Section 7.6 produce:

     WHILE stooge is Larry.

     WHILE stooge is Curly.

     WHILE stooge is Moe.

     

     IF stooge is Larry.

     

     FOREACH stooge is Moe.

     FOREACH stooge is Moe.

     FOREACH stooge is Moe.

Note that if the print within the foreach loop had referred to $_ rather than $&, its results would have been the same as the while's. In this foreach case, however, the result returned by the m/···/g, ('Larry', 'Curly', 'Moe'), goes unused. Rather, the side effect $& is used, which almost certainly indicates a programming mistake, as the side effects of a listcontext m/···/g are not often useful.