Re^3: How will you use state declared variables in Perl6?

[TimToady]

in reply to Re^2: How will you use state declared variables in Perl6?
in thread How will you use state declared variables in Perl6?

Well, technically, yes, you missed the demise of local, but only because we renamed it to temp and made it completely orthogonal to storage class declarations. You can temporize any variable, and it will restore itself at the end of the current lexical scope. You can also conditionally temporize a variable using let, and it resets at the block end only if the block fails. But these are operations on existing variables. Even in Perl 5, local never declares a variable, but merely temporarily changes the value of an existing global.

And to reiterate, state variables are not globals. They're persistent lexicals. You can temporize them, but then you can temporize my variables as well. You can even temporize attribute accessors and not worry about whether the accessor represents a real attribute or is a wrapper around something else:

    temp $handle.autoflush = 1;

[BrowserUk]

Okay. The analogy with C statics was flawed. That makes sense.

I should really have referred to our rather than local, but I think your explaination suffices.

What happens if I do:

sub bar {
    state $foo;
    ...
    my $code = sub qux {
        state $foo;
    };
    ...
}

• Is this illegal?
• Or do the two refer to the same thing?
• Or does the inner $foo hide the outer $foo for the duration of that scope?

[TimToady]

If it's illegal, it's because you took the address of a named declaration, not because of the state declarations. But ignoring the "qux" (and the entire question of whether that should be legal) your use of state variables would certainly be legal. The inner $foo hides the outer $foo just as a "my" variable would. And every time you clone the inner closure you'll get a new copy of the inner state variable, and it will initialize itself the first time that clone is called. It implies the existence of some kind of persistent lexical pad, which is a certain amount of work for the implementation, but we really didn't see much benefit in duplicating the functionality of globals, and a lot of benefit in having a kind of "my" that doesn't reinitialize the second time through.