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

Hi, kyle -

I seldom disagree with what you say ... in this case, however, I do, since assignment does indeed have a side effect since it returns a logical true when it was successful. Otherwise the following code would not work: 
if ( my $a = 2 )
{
    print "Assigned a value to $a";
}

[download]

(Yes, I know it produces a warning ... but it still runs ;-) Any comments?

Regards -

Pat

Replies are listed 'Best First'.
Re^5: map in void context
by chromatic (Archbishop) on Dec 20, 2008 at 21:09 UTC
    Any comments?

    That's like saying a subroutine has a side effect if it returns a value. If you start to argue that the value of an expression is a side effect, you'll prove that no language can be pure if it allows you to write expressions. (You can argue that if you want, but I'm not sure it gets you anywhere.)

[reply]
      Hey, cromatic -

      No, not at all since you cannot equate calling an operator with a call to a subroutine. I am not saying the return value of a subroutine is its side-effect - far from it ... because returning its return value is its effect (I have to admit I am not sure whether the call to a subroutine actually produces a side-effect in Perl - the Perl operators I am aware of certainly all do).

      An operator always returns a result (its effect) and may or may not (again, I am not sure if really all of Perl's operators produce side-effects systematically) also produce an additional change to the system state which would then be its side-effect.

      It's like taking a head-ache pill ... if makes my head ache go away, that's its effect. If, in addition, it makes me drowsy, that's its side-effect.

      Know what I mean?
[reply]

        The term "side effect" has a more specific meaning when talking about language constructs. You appear to be using the more general English meaning(s) of "side effect", which certainly isn't a good strategy for communication when surrounded by people using the programming-languages-specific term of art.

        The term originates from talking about places where you can use an expression but some expressions can have side effects. The main "effect" of an expression is the computed value. A side effect of the expression would be the changing of some persistent storage (changing the value of a variable whose lifetime extends beyond the life of the expression, writing I/O, reading I/O and thus changing the seek position in some stream, etc.).

        Now, considering just an assignment, it seems weird to refer to the actual assigning as a "side effect", as you noted. However, that is still what the technical term means. For example, a pure functional language doesn't allow side effects and thus has no such things as assignments.

        Now, map and grep accept expressions which determine how they act. And there are several ways to get an assignment included in such an expression (use the BLOCK-without-comma syntax, use do { }, call a sub, etc.). The return value is the part of such an expression that is important to map or grep. The assigning of a value to a non-temporary variable is what the term of art "side effect" means.

        So, yes, if just using the "plain English" term "side effect", you can look at an assignment inside of map/grep either way. But when talking about programming, using the term as you have tried to is mostly good for causing confusion.

        - tye        

[reply]
[d/l]

        No, not at all since you cannot equate calling an operator with a call to a subroutine.

        Why not? What's so fundamentally different between the following two lines? 

        $y = CORE::abs($x);    # operator
$y = POSIX::abs($x);   # sub

        [download]

        Would you even have known one was an operator and one wasn't had I not told you?

[reply]
[d/l]
Re^5: map in void context
by kyle (Abbot) on Dec 20, 2008 at 21:03 UTC

    It's not really returning "true", it's returning the value on the right side of the assignment. 

    my $x = 2;
print "\$x is '$x'\n";

if ( $x = 0 ) {
    print "\$x = 0 is true\n";
}
else {
    print "\$x = 0 is false\n";
}

print "\$x is '$x'\n";
__END__
$x is '2'
$x = 0 is false
$x is '0'

    [download]

    This behavior is why you can say "$x = $y = $foo" and set both $x and $y to whatever is in $foo.

    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 don't see it that way, however.

[reply]
[d/l]
[select]
[reply]
[d/l]
      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.
[reply]
[d/l]

        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)

        [download]

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

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

        [download]

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

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom