On Thu, 14 Sep 2000 08:47:24 -0700, Nathan Wiger wrote:
>One thing to remember is that regex's are already used in a number of
>functions:
>
> @results = grep /^VAR=\w+/, @values;
You are being mislead. You might just as well say that length() is being
used in other functions:
@results = grep length, @values;
This is not a regex as a prarameter. It is an expression. Execution is
postponed, just as for length(). The code is equivalent to
@results = grep { /^VAR=\w+/ } @values;
a block containing an expression. Now, to beconsequent, you should turn
this into:
@results = grep { match /^VAR=\w+/ } @values;
or
@results = grep match /^VAR=\w+/, @values;
Er... with the problem, that you no longer know what function the
argument list @values belongs to.
@results = grep macth(/^VAR=\w+/), @values;
Is this really worth it?
> @array = split /\s*:\s*/, $input;
You are correct here.
I'm opposed to an obligation to replace m// and s///. I won't mind the
ability to give a prototype of "regex" to functions, or even
*additional* functions, match and subst.
Bare regexes should stay.
As for tr///: this doesn't even use a regex. It looks a bit like one,
but it's an entirely different thing. And to me, the argument of tr///
is actually two arguments; a source character list, and a replacement
character list.
As for s///: same thing, two arguments, a regex, and a substitution
string or function. Your example function
OLD: ($str = $_) =~ s/\d+/&func/ge;
NEW: $str = subst /\d+/&func/ge;
should really be
$str = subst /\d+/g, \&func;
although I have the impression that the //g modifier is in the wrong
place.
--
Bart.
