> > make $__ mean "An alias for the
> > L-value of what the subroutine return value will get assigned to, or
> > ${undef} if we're not invoked as an R-value."
> A /much/ better syntax, in [John Mastros's] humble opinion. However,
> $__ must act sanely when we're called as an inner function (IE foo(bar(42))).
Given
sub foo($){ $__ = blarg(shift ); side_effect()};
$fred = foo(bar(42))
\$__ within bar would be \${foo's block::$_[0]};
\$__ within foo would be the same as \$fred
\$__ within blarg is also \$fred because $__ is blarg's lvalue
\$__ is \${undef} within side_effect because it is not called as an rvalue.
if we allow $__ to have meaning more than one deep we'll be in action-at-a-distance
land for sure.
> [john porter] thinks that's unnecessarily baroque. Just let $__ be an alias
> to the return value stack, the place where return() puts its
> args anyway.
That defeats the purpose of optimizing away the assignment from the return stack.
> In fact, shouldn't it be @__ ?
($a, $b, $c) = foo($_); # ref($__ ) is now ARRAY
This new variable could take the place of C<want>; or C<want> could mean C<ref($__)>
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
www.tmcm.com, dammit
