new "state" variables... nest properly??

Do the new "state" variable declaration stuff mean that finally you
can nest subs and variables will behave properly? Great news, if
true.

My little test program seems to indicate this is correct:

use strict; use warnings; use English; use feature 'state';

my( $GVar );

sub Outer{ my( $Arg ) = @_; state ( $Var );

sub Inner{
if( $GVar eq $Var ) { print "midvar is okay: $Var\n" }
else { print "midvar should be '$GVar' but is '$Var'\n" }
}

#begin Outer

if( $Var ) { print "*** Var preset!!! to '$Var' \n" }
else { print "Var unset as supposed to be!\n" }
$Var = $Arg;
$GVar = $Var;
Inner( );
}


print $];

Outer( 'foo 1' ); Outer( 'foo 2' ); Outer( 'foo 3' );

Re: new "state" variables... nest properly??

Quoth Abble :
> Do the new "state" variable declaration stuff mean that finally you
> can nest subs and variables will behave properly? Great news, if
> true.
>
> My little test program seems to indicate this is correct:
>
> use strict; use warnings; use English; use feature 'state';
>
> my( $GVar );
>
> sub Outer{ my( $Arg ) = @_; state ( $Var );
>
> sub Inner{

Named subs don't close over lexicals. That hasn't changed. This still
gives a 'Variable '$Var' will not stay shared' warnings, although since
the whole point of state vars is you only get one copy, this is not
terribly useful :).

What you are looking for is not state vars, but 'my sub'. There has been
a slot for this in the Perl grammar for a long time, but noone has ever
implemented it.

> if( $GVar eq $Var ) { print "midvar is okay: $Var\n" }
> else { print "midvar should be '$GVar' but is '$Var'\n" }
> }
>
> #begin Outer
>
> if( $Var ) { print "*** Var preset!!! to '$Var' \n" }
> else { print "Var unset as supposed to be!\n" }

This section 'fails': the second time through, $Var is already set,
since it preserves its value from last time Outer was called.

Ben

Re: new "state" variables... nest properly??

On Dec 27, 5:43 pm, Ben Morrow wrote:

> This section 'fails': the second time through, $Var is already set,
> since it preserves its value from last time Outer was called.
>
> Ben

yes, the "set locals to empty" bizness goes away, but it seems mid-
level variables now work.
In many cases I'm happy to have tio initialize locals and on exit
leave dangling variables if I get the benefit of being able to access
mid-level vars with impunity. It *seems* like we now have this.

Re: new "state" variables... nest properly??

On Thu, 27 Dec 2007 23:43:32 +0000, Ben Morrow
wrote:

>What you are looking for is not state vars, but 'my sub'. There has been
>a slot for this in the Perl grammar for a long time, but noone has ever
>implemented it.

For the record I had asked this quite some time ago:

http://perlmonks.org/?node_id=489881

To which dave_the_m replied:

: The perl5 parser has had a placeholder for lexical subs for quite a
: while [...] and a pad can quite happily accomodate them.
: The main things holding them up has been trying to agree their
: semantics, then someone - probably me - finding the time to implement
: them :-(.

Actually, I included it in my 5.12 wishlist @ PM:

http://perlmonks.org/?node_id=634043

Funnily enough, the issue has popped up again in a vaguely related
thread exactly today:

http://perlmonks.org/?node_id=659258


Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^ ..'KYU;*EVH[.FHF2W+#"\Z*5TI/ER 256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,

Re: new "state" variables... nest properly??

Quoth Michele Dondi :
> On Thu, 27 Dec 2007 23:43:32 +0000, Ben Morrow
> wrote:
>
> >What you are looking for is not state vars, but 'my sub'. There has been
> >a slot for this in the Perl grammar for a long time, but noone has ever
> >implemented it.
>
> For the record I had asked this quite some time ago:
>
> http://perlmonks.org/?node_id=489881
>
> To which dave_the_m replied:
>
> : The perl5 parser has had a placeholder for lexical subs for quite a
> : while [...] and a pad can quite happily accomodate them.
> : The main things holding them up has been trying to agree their
> : semantics, then someone - probably me - finding the time to implement
> : them :-(.

It would be rather awkward, as lots of code of the Clone/PadWalker type
assumes that anon <=> closure <=> '&' slot in a pad, and it would all
need to be changed.

What *I've* wanted for some time are lexical packages, or rather lexical
class names, but I don't think that would be possible as things like
->isa would break.

Ben