David L. Nicol wrote:
> sub subname(proto){
>
> # in here, the bareword "subname" is a magic
> # alias for the lvalue this routine is getting
> # assigned to, if any.
>
> }
>
> We could even define a new line noise variable which could hold the
> results of the last name-of-function subroutine that was not invoked
> as an rvalue (I nominate $__ ); make such an invokation a warning-level
> offense; and make $__ visibility/localization compatible with recursion.
I don't really see what this buys us. First, `return' already handles it,
and it finishes sub execution. How would it be handled with that? `foo = 42;
last;'? I think `return 42;' is better... And `return' handles scalar/list
context, mainly because it isn't a special variable, it is a statement. IMO,
`return' is perfect for the job, since it combines the familiarity of
passing a list as parameter to a statement, what is done in all practically
all Perl statements, and has no problem with context to return a scalar or a
list from a sub.
I really think that changing a familiar thing as `return', which is familiar
even to programmers of other languages, to a cryptic thing as $__/@__, just
to save the one value copy, isn't any good at all.
If optimization is _so_ needed, I think the parser/compiler should identify
those situations and optimize them in subs that use the same variable always
in `return' and bind it to the result value slot in the stack, or anything
like that, leaving the same `return' interface to the user.
- Branden
