http://www.perlmonks.org?node_id=1053916


in reply to Order of execution of functions in list

Reading the linked discussions reveals that the problem is related to lvalues and composed expressions (like ++$i) with side effects.

shift is a simple expression (a builtin in this case), has no side-effects and returns an rvalue.

Cheers Rolf

( addicted to the Perl Programming Language)

Replies are listed 'Best First'.
Re^2: Order of execution of functions in list
by ikegami (Patriarch) on Sep 13, 2013 at 13:26 UTC

    has no side-effects

    $ perl -E'@a=qw( a b c ); say 0+@a; shift(@a); say 0+@a;' 3 2

    returns an rvalue

    $ perl -E'$_=123; say; sub { sub { ++$_[0] }->(shift); }->($_); say;' 123 124
      The problem with mobiles is that I can't check my code (at least ATM)

      And I don't understand the sideeffect code you posted.

      I'll reply this evening...

      Edit

      At second glance it seems that shift really returns lvalues... Strange

      Mea culpa!!! :(

      Cheers Rolf

      ( addicted to the Perl Programming Language)

      > > returns an rvalue

      FWIW: I think this code is easier to understand and demonstrates your point

      DB<194> sub tst { my $x=\(shift()); ++$$x } DB<195> $a=10 => 10 DB<196> tst $a => 11 DB<197> tst $a => 12 DB<198> $a => 12
      I get the same results using the equivalent splice(@_,0,1)

      That's not documented in the perldocs for shift or splice and I think it's due to the way Perl holds and replaces variables in @_, they just don't loose their aliasing magic when shifted.

      Maybe Perl avoids copying of the values for performance reasons.

      Interesting...

      But since it's not documented, I doubt that this is reliable behavior.

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        But since it's not documented, I doubt that this is reliable behavior.

        It's an emergent behaviour; it's not by design.

Re^2: Order of execution of functions in list
by vsespb (Chaplain) on Sep 13, 2013 at 13:06 UTC
    has no side-effects
    shift() actually modifies @_, isn't it side-effect?
    if shift()s executed in different order, result will be different.
      Imho a main effect cause its a builtin function.

      Do you expect  sub inc { return $_[0] + 1} to cause ambiguity ?

      Ok ... Maybe better phrased "a well defined effect" my definition of side was to restricted.

      Cheers Rolf

      ( addicted to the Perl Programming Language)