[oak perl] Oakland.pm Meeting - Tuesday

[B.E.G.]

Belden responds to me:
> First: You use the phrase "avoiding regular expressions" to mean two
> different things. This is confusing.

There are three things in three examples:

1) Don't use regexps when you can do it faster another way.
2) Don't use regexps when it is too complicated to get right
   the first time but another method is right there.
3) Don't use regexps for things they cannot do.

> In the second sense, you show a delimited text example. Rather than
> using a regex attributed to Friedl, you suggest using Text::ParseWords.
> But Text::ParseWords uses regular expressions underneath. So does
> Text::Balanced.

Ah, but I didn't concern myself with what it underneath. It could be
written as a byte a time state machine. That is both the beauty and
danger of modules. I say "danger" because in some cases the modules
do so much under the hood, you might want to avoid them altogether.
Such was the case with CGI.pm before the CGI::Lite incarnation, at
least for me.


>	"Note also that the balanced parentheses requirement here (for
>	function calls as arguments) means regexps cannot do this."
>
> Regular expressions can do this. perlre.pod shows how to use the
> experimental C<(??{ code })> feature + C<qr()> to match nested parens;
> ``perldoc perlre'' to see how this works.

I remember it from this exchange:
http://groups.google.com/groups?selm=67mra9%24fm1%241%40agate.berkeley.edu

I meant to mention it, but forgot. That is a parlor trick, and not
useful in real world use. (Besides Perl's "regular expressions" do
not meet the standard mathematical definition of a "regular expression",
my statement is true for the mathematical definition.)

> See, I took that as a blank check to write back with whatever ramblings
> happened to pass through my mind. :)

Fair enough.

Elijah