Re^2: ternary operator as lvalue failing to induce evaluation of right-hand expression in list context

Deparse shows that the parentheses in the OP are unnecessary, which is as expected, since the conditional operator ?: has a higher precedence than assignment (see Operator Precedence and Associativity). Consider:

#! perl
use strict;
use warnings;

my @x = qw(Initial list of words 1);
my $y =   'Initial string 1';

show('With parentheses');
my @z = ( time() ? @x = qw(Words_z from conditional) : $y ) = foo();
print "\@z = (@z)\n";
show('After assignment to LHS');

@x = qw(Initial list of words 2);
$y =   'Initial string 2';

show('Without parentheses');
my @w =   time() ? @x = qw(Words_w from conditional) : $y   = foo();
print "\@w = (@w)\n";
show('After assignment to LHS');

sub foo
{
    if (wantarray())
    {
        print "\nfoo called in list context\n";
        return qw(sub_foo word list);
    }
    else
    {
        print "\nfoo called in scalar context\n";
        return 'String_from_foo';
    }
}

sub show
{
    my ($heading) = @_;

    print "\n$heading:\n\n";
    print "\@x = (@x)\n";
    print "\$y = '$y'\n";
}
[download]

Output:

17:35 >perl 678_SoPW.pl

With parentheses:

@x = (Initial list of words 1)
$y = 'Initial string 1'

foo called in scalar context
@z = (String_from_foo)

After assignment to LHS:

@x = (Words_z from conditional)
$y = 'Initial string 1'

Without parentheses:

@x = (Initial list of words 2)
$y = 'Initial string 2'

foo called in scalar context
@w = (String_from_foo)

After assignment to LHS:

@x = (Words_w from conditional)
$y = 'Initial string 2'

17:35 >perl -v

This is perl 5, version 18, subversion 0 (v5.18.0) built for MSWin32-x
+86-multi-thread-64int
[download]

It’s clear that foo is being evaluated in scalar context, even though the condition evaluates to true and so chooses the LHS. Since foo would still be evaluated in scalar context if the condition were false and the RHS chosen, it’s now clear why the compile error has disappeared: it is known at compile time that foo will be evaluated in scalar context.

But that leaves us with some unanswered questions:

What exactly is the l-value returned by the conditional expression?
Why does this l-value — which results from the assignment of a list to an array — put foo into scalar context?
Why does the assignment to @x seemingly occur after the call to foo?

I have the feeling that there’s an obvious answer to all this, but I can’t see it. Which is, just possibly, related to the fact that in my neck of the woods the Ashes coverage finishes around 3:30 am... |-O

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

Comment on Re^2: ternary operator as lvalue failing to induce evaluation of right-hand expression in list context Select or Download Code

Replies are listed 'Best First'.
Re^3: ternary operator as lvalue failing to induce evaluation of right-hand expression in list context by choroba (Cardinal) on Aug 05, 2013 at 09:36 UTC
This is strange. The output of Deparse -p is not parsed the same way as the original: `$ perl -MO=Deparse -e 'sub Foo{};(time ? @y=() : $x) = Foo()' \| per +l -e syntax OK $ perl -MO=Deparse,-p -e 'sub Foo{};(time ? @y=() : $x) = Foo()' \| per +l -e syntax OK Assignment to both a list and a scalar at - line 4, near "))" Execution of - aborted due to compilation errors.` [download] Perl 5.10.1 لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ	[reply] [d/l]
Re^4: ternary operator as lvalue failing to induce evaluation of right-hand expression in list context (accumulator) by Anonymous Monk on Aug 05, 2013 at 10:42 UTC
Compare `(time ? ($count=()) : $a) = Foo(); ## list+scalar (time ? @a : $a) = Foo(); ## list+scalar (time ? (@a=()) : $a) = Foo(); ## list+scalar (time ? $a=() : $a) = Foo(); ## scalar is scalar (time ? @a=() : $a) = Foo(); ## skates through as scalar $a[0]` [download] It appears perl doesn't recognize the array+assignment(accumulator) as a list without an extra parenthesis, so it does what it thinks should happen Is this a bug? Yes, in that it already protects programmers from this misunderstanding ( perldiag#Assignment to both a list and a scalar), but it missed this particular variant Also, Deparse isn't bulletproof :) Deparse says \my(%hash) is the same as \my %hash but it isn't	[reply] [d/l]
Re^4: ternary operator as lvalue failing to induce evaluation of right-hand expression in list context by ed_hoch (Sexton) on Aug 05, 2013 at 17:54 UTC
Thanks everyone for all the help. Again, with: `This is perl 5, version 16, subversion 2 (v5.16.2) built for x86_64-linux` I do: ~home>perl -MO=Concise, -ce '$z = (time ? @x=() : $x) = 365' e <@> leave[1 ref] vKP/REFC ->(end) 1 <0> enter ->2 2 <;> nextstate(main 1 -e:1) v:{ ->3 d <2> sassign vKS/2 ->e b <2> sassign sKS/2 ->c 3 <$> const(IV 365) s ->4 - <1> null sKPRM/1 ->b 5 <\|> cond_expr(other->6) sKRM/1 ->f 4 <0> time[t1] s ->5 a <2> aassign[t3] sKRMS* ->b - <1> ex-list lK ->7 6 <0> pushmark s ->7 - <0> stub lP ->- - <1> ex-list lK ->a 7 <0> pushmark s ->8 9 <1> rv2av[t2] lKRM/1 ->a 8 <$> gv(x) s ->9 - <1> ex-rv2sv sKRM/1 ->- f <$> gvsv(x) s ->b - <1> ex-rv2sv sKRM/1 ->d c <$> gvsv(z) s ->d -e syntax OK [download] versus ~home>perl -MO=Concise, -ce '$z = (time ? (@x=()) : $x) = 365' Assignment to both a list and a scalar at -e line 1, at EOF -e had compilation errors. e <@> leave[1 ref] KP/REFC ->(end) 1 <0> enter ->2 2 <;> nextstate(main 1 -e:1) :{ ->3 d <2> sassign KS/2 ->e b <2> sassign KS/2 ->c 3 <$> const(IV 365) s ->4 - <1> null KP/1 ->b 5 <\|> cond_expr(other->6) K/1 ->f 4 <0> time[t1] s ->5 a <2> aassign[t3] KPS ->b - <1> ex-list lK ->7 6 <0> pushmark s ->7 - <0> stub lP ->- - <1> ex-list lK ->a 7 <0> pushmark s ->8 9 <1> rv2av[t2] lKRM/1 ->a 8 <$> gv(x) s ->9 - <1> ex-rv2sv sK/1 ->- f <$> gvsv(x) s ->b - <1> ex-rv2sv sK/1 ->d c <$> gvsv(z) s ->d [download] There are several differences, starting with the fact that in the first case (the case where it compiles, but I would have expected it not to), apparently the assignment to the ternary is parsed as scalar context (s), where in the second case (the case where it gives compiler errors, as I would have expected), the context isn't indicated. perlop indicates that for a conditional expression, the scalar/list context propagates down to the 2nd or 3rd argument. I suspect something wild is going on with parsing `"@x=()"` and `"(@x=())"` as scalar lvalues, where the first is legitimate, and the second isn't. This is really just a guess, though.	[reply] [d/l] [select]