> If =~ allowed "indirect object" notation as -> does, then we could write
>
> s $str (pat){rep};
> and
> for ( grok %db /Name/$name/g ) {
Yeah, but I'm not sure what those are supposed to do. They look way too
obscure for me.
As written I don't see an advantage in the RFC. I think it confuses
regexps and subs, which are two completely different things. I don't see
any advantage to being able to call these interchangeably:
dostuff($one, $two, $three);
dostuff/$one/$two/$three/;
That's another way to do things, sure, but so is this
$three|$two|$one:::dostuff
But I don't think either is an *advantage*.
However, I don't think the RFC is totally without merit. I would drop
the // overloading and just look at =~, since that's a neat operator.
Here's a somewhat different approach that you hint at with =~. You say:
> $foo =~ greek/alpha/beta;
> would be the same as the following in old syntax:
> greek( \$foo, 'alpha', 'beta' );
This is interesting. But let's forget about // for now. A lot of times,
I find myself doing stuff like this:
($user) = split /,\s*/, $user;
$string = quotemeta($string);
What if =~ had a very similar effect to what you descibe, only it passed
the argument as the *last* one (you show the first). The above now
become:
$user =~ split /,\s*/;
$string =~ quotemeta;
Hmmm. I'm kinda liking this. With an upcoming RFC I just submitted on
replacing m// and s///, you could make the old Perl 5:
$string =~ s/old/new/gi;
Equivalent to the new Perl 6:
$string = s/old/new/gi, $string;
syntax. Plus, you add generality enabling this for all functions. To me,
that seems pretty cool.
-Nate