What about?
sub foo { lreturn ($one, $two, $three); }
foo = (0..10);
or
foo = &bar;
The compiler needs to know what foo is returning. The attribute tells
perl evaluate foo to determine the context (i.e. where to put the
dirty laundry) and the goes ahead and does the rest.
If you do it as scalar only. You lose a lot of useful possiblities.
Why do you mind having an attribute?
Is there anyting in perl that defines the order of evaluation?
$foo[$a] = $bar[$a++];
If there isn't, then we should be free to invoke the left hand side
to determine the context.
And the attribute allows the compiler to build an optimized optree
in the non-lvalue case.
<chaim>
>>>>> "JV" == Johan Vromans <[EMAIL PROTECTED]> writes:
JV> Damian Conway <[EMAIL PROTECTED]> writes:
>> [EMAIL PROTECTED] (Randal L. Schwartz) writes:
>>
>> > So is that something we've agreed, that lvalue subs are *always*
>> > scalars? That'd mean we can move on to the various implementation
>> > details. :)
>>
>> Err, I for one would like to see *any* data types lreturn-able.
JV> So do I. But, as Randal pointed out, there seems to be a catch here.
JV> With the "scalar lreturn" proposal the sub definition does not need
JV> something special (like an :lvalue attribute) and, more important, the
JV> compiler need not know whether a sub call might involve an lvalue
JV> returning sub, or a sub that chooses to actually do an lreturn.
JV> A sub is not lvalued by declaration, it may return an lvalue if it
JV> decides to do so.
JV> All other proposals I've seen not only require special attributes
JV> and/or parameter specs for the subroutine definition (which is not a
JV> problem per se), but also seem to require that the compiler knows it's
JV> compiling an lvalue sub call, and hence this sub must be predeclared
JV> or otherwise made known to the compiler. A sub is lvalued or not, and
JV> the compiler must know. And this seems to be virtually impossible when
JV> method calls are involved.
JV> -- Johan
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
