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.

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?

ikegami -

From a formal point of view there is, of course, a huge difference between calling a subroutine or using an operator - even if the difference is not discernable in Perl from their surface strings as you illustrate (other programming languages, of course, choose to handle this differently). I am not talking about how the input and output data get shifted around in memory here. The main difference from a formal perspective is that operators are part of the language inventory (its lexicon, to be precise) while subroutines are user-defined constructs based on language inventory and hence do not belong to the inventory themselves. As a result, operators may have additional properties - such as side-effects - associated with them by definition while subroutines do and cannot (as far as I am aware I cannot define side-effects for a subroutine in Perl).

To come up with a uniform argument on the production of side-effects by Perl commands (not statements!) one may wish to argue that the side-effect of a subroutine call is identical to its return value ... this behaviour would permit (the meaningful?) generalisation that every construct in Perl involving an operator (be it Perl-internal or user-defined) and its operands returns its return value plus one or more side-effect(s).

... as far as I am aware I cannot define side-effects for a subroutine in Perl....

It's easy:

use 5.010;

sub square_a_number
{
    my $value = shift;
    $Some::Global::Variable += $value;
    say "Squaring the value '$value'";
    return $value * $value;
}
[download]

There are two trivial side effects, as well as the non-obvious side-effect of setting SvNOK on $value.