in reply to Re^5: map in void context
in thread map in void context

Hi, kyle -

Thanks for correcting my comment regarding the return value of the assignment operator =. I guess, the actual return value (namely the value assigned) is a perfect example for the informative return values of Perl operators I was commenting on earlier - and further down - in this thread.
If you consider the "effect" of assignment to be returning the value of the right hand side, then perhaps changing the value of the variable is a side effect.
I would say it exactly the opposite way: The effect of assignment is assigning a value. Its side-effect is that it also provides a return value (which just makes me wonder about list assignments ... must check if their return value really is a list of all assigned values).

But OK - I think we now understand the way the other party is seeing things. Agreement must not necessarily be achieved. Thanks for responding again, anyway.

Replies are listed 'Best First'.
Re^7: rv of list assignment (was "map in void context")
by ikegami (Patriarch) on Dec 21, 2008 at 21:10 UTC

    which just makes me wonder about list assignments ... must check if their return value really is a list of all assigned values

    In list context, list assignment evaluates to the list of elements actually assigned.

    my @x = ($a,$b) = (4,5,6); # @x = (4,5)

    In scalar context, list assignment evaluates to the number of elements to assign.

    my $x = ($a,$b) = (4,5,6); # $x = 3

    Remember, x = y = z means x = ( y = z ) because assignment is right-associative.

      Thanks, ikegami, for the clear proof that indeed the side effect of list assignment is that a list of all values assigned is returned!

      This is a consistent extension of the behaviour of the assignment operator in scalar context and exactly in line with what I would have expected.

      To re-state my point: ikegami's code only works because of the side-effects associated with the assignment operator (To my personal surprise, ikegami mentioned earlier in this thread that
      Side-effects are something to be avoided when programming.
        Avoiding side-effects does not mean not understanding them. And we may use techniques in example code that we avoid in production code.

        That's not what I said it returns. You ignored half the answer. Whatever you claimed to have proven probably wasn't.

        To my personal surprise, ikegami mentioned earlier in this thread that

        You can't use a different definition of "side-effects" and assume what other people said about them still applies. According to the definition I was using, the assignment has no side-effects. But I'm fine with with what I said even when using the functional programming definition. It's not that the assignment operators shouldn't be used, it's that creating operators and subs with side-effects should be done with care.