[I know this is not your quote, but your quotee's quote]

>> There is obviously no need to modify the behavior of the C<&&> operator.

Is one wholly certain of this?

      DB<1> @c = (1..3)
      DB<2> @a = @b && @c
      DB<3> x @a
    0  0
      DB<4> x @b
      empty array

It's hard to argue that @a now holds the same thing as @b hold,
or that, given the suggestion to alter || as described in the
cited message, that && should not also behave correspondingly.

Without referring to (grammatical) number, the && case is:
    "Set a to b if b is false, otherwise set a to c".
Whereas the || case is:
    "Set a to b if b is true,  otherwise set a to c".

They seem analogous today, and one does not hope to see suggested
that that analogy be broken.

For now, the hook-colon workaround is used:

    @a = @b ? @b : @c;  # not @b || @c
    @a = @b ? @c : @b;  # not @b && @c

It's admittedly awkward to explain why 

    $a = $b || $c;
    $a = $b && $c;

work that way, yet for non-scalars, they don't:

    @a = @b || @c;
    @a = @b && @c;

    %a = %b || %c;
    %a = %b && %c;

    @a = &b || &c;      # even trickier, as context would alter
    @a = &b && &c;

But up to now, it's been deemed easier to use ?: than to diddle how
that all works.

Note that, contrary to popular repetition, it is not in point of
fact altogether unheard of for Perl to actually call something in
list context when it nevertheless wants only a scalar result as a
result of that expression.  For example:

    $a = \(b(), c());

That produces a reference to the last scalar in the list returned
from having called c() in list context.  This would appear to
circumvent the oft-cited notion that there are no lists in scalar
context, but don't tell anybody I told you that. :-)

It would appear that altering &&/|| on LHS context would entail,
in the list assignment scenario, calling that operand in list context
and then deciding whether it were true or not by some "intuitive"
means (almost certainly by using whether its element count were
zero or non-zero).  You'd have to squirrel away those list values
first to avoid re-evaluation, but this does not seem unduly onerous.

--tom

Reply via email to