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

I don't consider assignment to have a "side effect". Assignment is the effect. It might have a side effect if I'm working with a tied variable, I guess, but that's out somewhere else.

Another difference between for and map is what happens when the BLOCK modifies the array that it's iterating over. 

my @x;

# loops once
@x = qw( x );
map { push @x, 'x' } @x;

# loops forever
@x = qw( x );
push @x, 'x' for @x;

[download]

Replies are listed 'Best First'.
Re^4: map in void context
by pat_mc (Pilgrim) on Dec 20, 2008 at 20:44 UTC
    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
[reply]
[d/l]
      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]

      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]
Re^4: map in void context
by almut (Canon) on Dec 17, 2008 at 16:54 UTC
    Another difference between for and map is what happens when the BLOCK modifies the array that it's iterating over.

    One could argue that this difference is just a side-effect of the specific implementation. ;)

[reply]
[d/l]
[select]
Re^4: map in void context
by JavaFan (Canon) on Dec 17, 2008 at 17:04 UTC
    I don't consider assignment to have a "side effect". Assignment is the effect.
    So, 
    map {$sum += $_} @array;

    [download]
    is side-effect free?
[reply]
[d/l]
      I don't consider assignment to have a "side effect". Assignment is the effect.
      So, 
      map {$sum += $_} @array;

      [download]
      is side-effect free?
      This seems disingenuous. While I agree that arguing that assignment is “side-effect free” seems a little strange, your example isn't just assigning, it's mutating. Even in the purest of functional languages, x = 5 is OK (I think!); but x += 1 isn't.
[reply]
[d/l]
[select]
        In a pure functional language, there is no assignment (there are no variables either - there are identifiers, but their values don't vary over time). x = 5 isn't an assignment. It just means that x is 5. Unlike an assignment which says that x becomes 5 (meaning that it could be something else before, and may become something else later).
[reply]
[d/l]

In Section Seekers of Perl Wisdom