Front page | perl.perl6.language |
Postings from August 2000
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
C<||> and C<&&> should propagate result context to both sides
=head1 VERSION
Maintainer: Peter Scott <peter@psdt.com>
Date: 5 Aug 2000
Last-Modified: 29 Aug 2000
Mailing List: perl6-language@perl.org
Version: 3
Number: 45
Status: Frozen
=head1 ABSTRACT
Currently the expressions
lvalue = expr_A || expr_B
lvalue = expr_A && expr_B
evaluate C<expr_A> in scalar context, regardless of the type of C<lvalue>,
only propagating list or scalar context to C<expr_B>. This proposal is
that the context of C<lvalue> should be propagated to C<expr_A> as well.
=head1 DESCRIPTION
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 C<@b> (or the list
expression in its place) has to be evaluated in scalar context to determine
whether to evaluate C<@c>, and that propagating context to C<@b> would
require reevaluating it, which might have undesirable side effects (instead
of C<@b>, it might be C<decrement_balance()>).
Tom Christiansen pointed out that for consistency, both C<||> and C<&&> need to
be changed, since in the latter case, if C<@b> is empty, then C<@a> will
currently get the single element 0. We want it to get an empty list.
=head1 IMPLEMENTATION
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 C<@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.
=head1 IMPACTS
L<RFC 82> would require a different interpretation, namely that the result
would be the list formed by applying C<&&> or C<||> to each successive pair
of elements in C<@b> and C<@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.
=head1 REFERENCES
L<perlop/"C-style Logical Or">
RFC 21: "Replace C<wantarray> with a generic C<want> function"
RFC 82: "Apply operators component-wise in a list context"