[Israel.pm] The qr// operator

Levenglick Dov-RM07994 dov at freescale.com
Thu Jan 1 00:16:47 PST 2009

Let's not forget the /x operator if readability is your goal:

The /x modifier itself needs a little more explanation. It tells the
regular expression parser to ignore whitespace that is neither
backslashed nor within a character class. You can use this to break up
your regular expression into (slightly) more readable parts.


    The following pattern matches a function foo() which may contain
balanced parentheses as the argument.

      $re = qr{ (                    # paren group 1 (full function)
                  (                  # paren group 2 (parens)
                      (              # paren group 3 (contents of
                       (?> [^()]+ )  # Non-parens without backtracking
                       (?2)          # Recurse to start of paren group 2

Best Regards,
Dov Levenglick
SmartDSP OS Development Leader

-----Original Message-----
From: perl-bounces at perl.org.il [mailto:perl-bounces at perl.org.il] On
Behalf Of Gaal Yahas
Sent: Wednesday, December 31, 2008 00:50
To: Perl in Israel
Subject: Re: [Israel.pm] The qr// operator

There are several reasons why you might want to use qr// rather than
create a large string and get it compiled at the last minute.

There's performance, as you mentioned. Sometimes it matters that the
regexp be compiled only once.

You may be getting the regular expression from an external source,
like a config file or the user (imagine an editor with a "find with
regular expression" feature). You want to eval { qr// } the input
immediately, and inform the user of any errors before attempting to do
any matches.

Composing large regexps out of small ones is incredibly useful for
parsing complex languages. This is limited in occasion with Perl 5
regexps(*), because their captures are positional (i.e., you have to
know exactly what to expect in $1, $2 etc.), but can get you very far
with Perl 6 Rules, which are wonderfully compositional. For example,
if you have a Rule parsing a number (and returning a Number object),
and a Rule parsing an arithmetic operation (and returning an Operation
object), you just have to add a third Rule parsing and returning an
Expression, and there you go, you have a grammar for a calculator,
that when run successfully against some input, returns a tree
structure. And this is easily maintainable; if you want your parser to
start supporting new a Operation, you know exactly where to extend it.

(*) Perl 5.10 improves this, though.

On Wed, Dec 31, 2008 at 12:17 AM, Eli Billauer <eli at billauer.co.il>
> The open question here is about performance. As for readability, the
> example shows pretty clearly that a complex regular expression can be
> made accessible to mortals.
> And yes, I suppose that gradually creating a complex regular
> as a string, with parentheses carefully put in place, would do the
> Have you ever seen someone doing that?
> The point is, that for some reason, setting up a regular expression in
> stages is pretty rare (read: never seen it until now). What is much
> commonplace is a bombardment of cryptic characters. And I sincerely
> wonder if there is any reason in the world why regular expressions
> should look that way.
>   Eli
> Avishalom Shalit wrote:
>> isn't qr a performance thing ?
>> couldn't you have gotten the same readability with strings ?
> --
> Web: http://www.billauer.co.il
> _______________________________________________
> Perl mailing list
> Perl at perl.org.il
> http://perl.org.il/mailman/listinfo/perl

Gaal Yahas <gaal at forum2.org>
Perl mailing list
Perl at perl.org.il

More information about the Perl mailing list