>From rfc 98: 

 
> =head2 acceptable coercions
> 
> When resolving which method C<foo()> to call in a context CTXT, and there
> is no method  C<foo()> defined for the context CTXT, Perl will examine
> the types listed in C<@CTXT::ISA{OVERLOAD_CONTEXTS}> for a list
> of other contexts
> to see if C<foo()> can produce, before throwing an error.  This search
> is NOT recursive, unless defined so by the tying of the array to a
> dynamic iterator.
> 
> =head2 ambiguity resolution
> 
> In situations where multiple interpretations are possible, such
> as the f(g()) situation, the first possible method that will work
> is called.
> 
> The search order is based on the preferences of the outer function,
> then the preferences of the inner function.
> 
> Functions maintain their preference order in an array
> 
>         @PACKNAME::methodname{OVERLOAD_PREFERENCES}
> 
> and the first context specifier found in that array, which can be
> satisifed with a call to the named method, is used.
> 
> If no such array exists,
> 
>         @PACKNAME::OVERLOAD_PREFERENCES 
> 
> is consulted.
> 
> Perl6 maintains a global @CORE::OVERLOAD_PREFERENCES which begins
> with C<qw(ARRAY SCALAR)> and has all types declared in the program
> appended to it as they appear, which is used when neither a method 
> nor its class does not
> provide its own OVERLOAD_PREFERENCES array.


Following the amibuity resolution rules in rfc98, we could look at
@lvsub{OVERLOAD_PREFERENCES} and see what it is promising us.

Which may be more or less work than adding a specifier around
the subroutine call; it is acceptable if you are developing a module

both may be unacceptable if you are a beginner trying to
use a prebuilt module.



"Randal L. Schwartz" wrote:

> How do you indicate to the compiler at the time of compiling:
> 
>         lvsub() = FOO
> 
> that FOO should be evaluated in list context?  Or scalar context?
> Because FOO needs to know that while it is executing, before invoking
> your subroutine.  Or do you imagine invoking your subroutine before
> evaluating the right side of the code (so it can return a scalar/list
> flag of some kind), thereby breaking the normal model of assignment
> where the right side gets run first?
> 
> This is the sticky point that keeps hanging up lvalue subs.  Perl's
> context transfer on the assignment operator keeps getting overlooked.

um, @{lvsub()} = ...

or ${lvsub()} = ...

but those kind of take the fun out of having an "l-value subroutine"
don't they

Reply via email to