{
        my $x = 42;
        my $s = sub { $x++ };
        say &$s();
    }
[download]

    my $s = sub { state $x = 42; $x++ };
    say &$s();
[download]

This makes little difference with the two snippets above, since in the first example the my also creates a new $x every time you execute the snippet, but if you created $x only once, and then created the closure multiple times in a loop, you'd notice that the single my $x is shared among them.

However, that difference is not why we introduced state variables. The big win is the psychological one of not having to look outside of the sub to find the definition of $x. (That, and we wanted it as a primitive in Perl 6 so that people could write stateful macro constructs without forcing the user to define the state variable externally; in fact, we also use it ourselves in order to implement the stateful flipflop operator without having to build the flipflop in as a primitive, as it is in Perl 5.)

Note also that with state each created anonymous sub gets its own copy of $x

Hmmm... but you can get the same result with the closure approach:

sub get_counter {
   my $x = 42;
   return sub {
      $x++;
   }
}
my $s = get_counter();
say &$s();
[download]

However, that difference is not why we introduced state variables. The big win is the psychological one of not having to look outside of the sub to find the definition of $x.

Nice, that reason convince me (and the one that kyle gave below).

Thanks

citromatik

The main difference I see is that the initialization of state variables only happens when the function is called. Consider:

use feature qw( :5.10 );

sub uncalled_sub {
    state $huge = huge_data_structure();
    return;
}

print 'mem usage: ', my_mem(), "\n";

sub huge_data_structure {
    return [ ( 'x' x 1_000 ) x 100_000 ];
}
sub my_mem {
    my ($proc_info)
        = grep { $_->[2] == $$ } map { [ split ] } `ps l | tail -n +2`
+;
    return $proc_info->[6];
}
__END__
mem usage: 11220
[download]

Compare to:

{
    my $huge = huge_data_structure();
    sub uncalled_sub {
#        state $huge = huge_data_structure();
        return;
    }
}

print 'mem usage: ', my_mem(), "\n";
__END__
mem usage: 116132
[download]

Both tests were performed with Perl 5.10.0. You get the same kind of side effect (with time instead of memory) if initialization is a long_arduous_task().

Consider also:

print counter(), "\n";
{   
    my $count = 0;
    sub counter { $count++ }
}
print counter(), "\n";
__END__
0
0
[download]

Compare to:

use feature qw( :5.10 );

print counter(), "\n";
sub counter {
    state $count = 0;
    return $count++;
}
print counter(), "\n";
__END__
0
1
[download]

Under ordinary circumstances, you won't notice either problem. Your initialization is fast, and it happens inside something you used, not in the middle of your program.

I think it also helps maintainability. You have the variable that's relevant to the function inside it instead of outside it. Even if they're right next to each other (as you have them), they could get separated later, and you don't want one of them left behind in some refactoring.

The main difference I see is that the initialization of state variables only happens when the function is called

Yes, that is a good difference. Thanks!

Consider also:

print counter(), "\n";
{   
    my $count = 0;
    sub counter { $count++ }
}
print counter(), "\n";
__END__
0
0
[download]

This one is easy to overcome, just putting the code in a BEGIN block:

print counter(), "\n";
BEGIN{   
    my $count = 0;
    sub counter { $count++ }
}
print counter(), "\n";
__END__
1
0
[download]

citromatik

Since I find the latter very simple to follow and understand I would like to know if there are differences between them

Do you know the difference between a hippo?

Each sub has its own scope, so sharing a lexical state variable via state $var is not an option, you have to allocate that var in an outer scope. my and state make no difference there.

_($_=" "x(1<<5)."?\n".q·/)Oo.  G°\        /
                              /\_¯/(q    /
----------------------------  \__(m.====·.(_("always off the crowd"))."·
");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}

One particular itch that needed scratching, apart from some of the points that TimToady makes, is that it got rid of the ugly state-with-a-my hack that went something like:

  my $persist if 0;
[download]

That particular construct breaks through the abstraction of the language and hits an oddity in the way lexicals are implemented. The result of which was, when used in a routine, a variable that maintained its previous value next time the routine was called.

It was a sufficiently desirable trick that it was independently discovered time and again, by people who understood the language sufficiently deeply, and tried it out and were happy to discover that it worked.

Unfortunately, it was also regularly discovered by people who had no idea what was going on, and it led to bugs that were difficult to understand and fix (especially when the if 0 was buried under a complex expression).

So one of things that went into 5.10 was the outlawing of my $foo if 0 to stop people shooting themselves in the foot, and the introduction of state variables, for those who needed them.

• another intruder with the mooring in the heart of the Perl

So one of things that went into 5.10 was the outlawing of my $foo if 0

Why still allow my $foo if $bar; ? Such seems, if anything, worse than the if 0 construct. I can understand putting it through a deprecation cycle but not even that was started.

- tye