Quoting RFC 23:
> That is, the expression:
>
> $check = __ < 2 + __ * atan($pi/__) or die __;
>
> is equivalent to:
>
> $check = sub (;$$$$) {
> $_[0] < 2 + $_[1] * atan($pi/$_[3]) or die $_[4]
> };
It strikes me that this is very fragile and limited (unless I
misunderstand, which is quite possible). For one thing, it appears to
only be useful if your subroutine uses each argument exactly once. If
you need to use any of the arguments more than once, you can't use this
notation. For example, you might want to check $_[3] to be sure
$pi/$_[3] didn't end up dividing by zero. I don't see how to to that
with the __ version.
Further, if you find you need to revise the check function in a way
that changes the order in which the arguments are used, but you don't
want to replace all the calls to $check elsewhere in your code, I
don't see how you can do that with the __ version.
Thus it seems to me that this notation doesn't really buy us very much.
It's only useful for a very specialized set of subroutines. Of course you
have to realize I had never heard of either "higher order functions" or
"Re-currying deferred expressions" prior to reading this RFC, so it's
quite possible I'm missing something.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
