Re: adding items, but with interim results

[kcott]

G'day kontrapunktstefan,

Welcome to the monastery.

Your description is ambiguous. I suspect #0+1, 1+3, 3+2 should be #0+0, 0+1, 1+3, 4+2. If this is actually what you want, there are many ways to code it; here's one:

$ perl -Mstrict -Mwarnings -E '
    my @x = (0,1,3,2);
    my @y = map { state $z = 0; $z += $_ } @x;
    say "@y";
'
0 1 4 6

[AnomalousMonk]

my @y = map { state $z = 0; $z += $_ } @x;

The use of the state scalar variable  $z in the map BLOCK in this statement is neat, but it presents a stumbling block to which it is perhaps unwise to expose a novice lest he or she be precipitated, however inadvertently, from the True Path.

A state variable, of course, maintains its state from one access to the next regardless of whether or not the lexical scope enclosing the variable is exited and re-entered. This is fine if the statement containing the variable is executed once and only once in the execution of a program; if it is not, the results may be surprising. (In the example below the source array  @w is repeatedly dumped just to show that it never changes.)

>perl -wMstrict -MData::Dump -lE
"sub summer { return map { state $z = 0;  $z += $_; } @_; }
 ;;
 my @w = qw(0 1 3 2);
 my @x = summer(@w);
 my @y;  @y = map { state $z = 0;  $z += $_; } @w for 1 .. 3;
 my @z = map { state $z = 0;  $z += $_; } @w;
 ;;
 dd \@w;
 dd \@x;
 dd \@y;
 dd \@z;
 ;;
 @x = summer(@w);
 @y = map { state $z = 0;  $z += $_; } @w for 1 .. 3;
 @z = map { state $z = 0;  $z += $_; } @w;
 ;;
 print '----------';
 dd \@w;
 dd \@x;
 dd \@y;
 dd \@z;
 ;;
 print '----------';
 dd \@w;
"
[0, 1, 3, 2]

[0, 1, 4, 6]

[12, 13, 16, 18]

[0, 1, 4, 6]

----------
[0, 1, 3, 2]

[6, 7, 10, 12]

[12, 13, 16, 18]

[0, 1, 4, 6]

----------
[0, 1, 3, 2]

[LanX]

> but it presents a stumbling block to which it is perhaps unwise to expose a novice

I second this!

Especially because state has some implementation issues besides needing to be activated with use feature.

a simple my $z outside the map has the same effect and is backwards compatible.

   DB<104> @x=1..4
 => (1, 2, 3, 4)

  DB<105> use feature state; my @y = map { state $z = 0; $z += $_ } @x
+;
 => (1, 3, 6, 10)

  DB<106> my $z; my @y = map { $z += $_ } @x;
 => (1, 3, 6, 10)

and if the scope of $z is of importance, use blocks to limit it.

  DB<107> my @y; { 
           my $z;
           @y =  map { $z += $_ } @x;
          }
 => (1, 3, 6, 10)

  DB<109> my @y = do { my $z; map { $z += $_ } @x }
 => (1, 3, 6, 10)

[LanX]

IMHO it's not state which is buggy but rather map.

see this

  DB<168> sub tst (&@) { my $cr=shift; print $cr->($_)," " for @_ }

  DB<169> use feature 'state'; tst {state $i++} 1..3 for 1..3
 => ""
0 1 2 0 1 2 0 1 2

The blocks of map and grep are no anonymous subroutines as Tobyink pointed out recently.

IMHO thats why scoping fails in your tests.

  DB<173> use feature 'state'; map {state $i++; print "$i "} 1..3 for 
+1..3
 => ""
1 2 3 4 5 6 7 8 9

(at least with 5.10)

udate

also while conditions

  DB<195> use feature 'state'; for (1..3) { $y=0;while (++(my $x)) { p
+rint " $x .";last if $y++>3 } }
 => ""
 1 . 1 . 1 . 1 . 1 . 1 . 1 . 1 . 1 . 1 . 1 . 1 . 1 . 1 . 1 .
  DB<196> use feature 'state'; for (1..3) { $y=0;while (++(state $x)) 
+{ print " $x .";last if $y++>3 } }
 => ""
 1 . 2 . 3 . 4 . 5 . 6 . 7 . 8 . 9 . 10 . 11 . 12 . 13 . 14 . 15 .