[% setvar title C<||> and C<&&> should propagate result context to both sides %]
Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
||
and &&
should propagate result context to both sides
Maintainer: Peter Scott <peter@psdt.com> Date: 5 Aug 2000 Last Modified: 29 Aug 2000 Mailing List: perl6-language@perl.org Number: 45 Version: 3 Status: Frozen
Currently the expressions
lvalue = expr_A || expr_B lvalue = expr_A && expr_B
evaluate expr_A
in scalar context, regardless of the type of lvalue
,
only propagating list or scalar context to expr_B
. This proposal is
that the context of lvalue
should be propagated to expr_A
as well.
It would be nice to be able to say
@a = @b || @c
instead of having to resort to
@a = @b ? @b : @c
The reason that it is not currently possible is that @b
(or the list
expression in its place) has to be evaluated in scalar context to determine
whether to evaluate @c
, and that propagating context to @b
would
require reevaluating it, which might have undesirable side effects (instead
of @b
, it might be decrement_balance()
).
Tom Christiansen pointed out that for consistency, both ||
and &&
need to
be changed, since in the latter case, if @b
is empty, then @a
will
currently get the single element 0. We want it to get an empty list.
It seems that it ought to be possible to evaluate something in a list
context and test whether there are any entries in the resulting list
without having to reevaluate the expression in a scalar context. The
work-around with the trinary operator also evaluates @b
twice (which
H.Merijn Brand pointed out could even be tied and hence evaluation not
idempotent).
It's true that we are evaluating something in list context and then applying a boolean interpretation to the result (empty list is false, otherwise true); in this case we are trading a lesser consistency (likely only to be appreciated by someone who's been thinking for a long time about contexts) for a greater one.
"RFC 82" would require a different interpretation, namely that the result
would be the list formed by applying &&
or ||
to each successive pair
of elements in @b
and @c
. This author likes the idea of certain
component-wise operators, and appreciates the importance of consistency,
but just can't see a component-wise interpretation of the logical operators
being either useful or intuitive.
"C-style Logical Or" in perlop
RFC 21: "Replace wantarray
with a generic want
function"
RFC 82: "Apply operators component-wise in a list context"