Re: state vs my
On Fri, 3 Dec 2004, Brent 'Dax' Royal-Gordon wrote: Larry Wall [EMAIL PROTECTED] wrote: So optimizing to a state variable won't necessarily help your loop overhead, but it could help your subroutine overhead, at least in Perl 5, if Perl 5 had state variables. Best you can do in Perl 5 is an our variable with an obscure name. my $x if 0; I know it's *going* away, but it hasn't *gone* away yet. Personally I'm glad this is going away. I'm not bothered by the caveats of the docs: it's the construct itself that somehow strikes me as innatural, to the point that I've never been bitten in the neck by using it inadvertently for I would have never ever though about doing so... In fact a declaration is fundamentally a way to introduce an object to be used subsequently, and the fact that it can be used also in the same statement in which it is declared doesn't make things really different. So how can I *declare* something depending on a condition?!? I can branch over a condition to execute either one block or another *within* which things can be declared or some such. Not the other way round... Michele -- A question out of curiousity: who is this Green of Green's functions? Is he the same person of Green's theorem? :) Yes. He was also an early environmentalist; hence the current phrases green this and green that... - David C. Ullrich on sci.math, thread Who is Green?
Re: state vs my
On Sat, 4 Dec 2004 22:03:19 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sun, Dec 05, 2004 at 02:15:51AM +0300, Alexey Trofimenko wrote:
: oh! that it. I've found example which could make it clear to me
:
: sub test {
: return sub {
: for 1..3 {
:state $var = 1;
:print $var++
: }
: }
: }
:
: $a = test; $a() for 1..3; print ';'
: $b = test; $b() for 1..3;
:
: that could print, for different possible definitions of state:
: 1) 123123123;123123123
: 2) 123456789;123456789
: 3) 123456789;101112131415161718
:
: looks like you meant third(!) variant.. but it doesn't make any sense
: for me.
I don't know how you even get the third variant. I think it should be 2,
though I see how you'd get 1 if you think a loop clones every time
through.
third variant is what we get if we replace Cstate with perl5 my $var if
0 here (not exactly, because $var start value would be undef in that
case).
Certainly that one doesn't, since it doesn't refer to any external
lexicals.
Perhaps statehood should be limited to official subs just like
return is.
they must be limited. It would be really strange if
sub test {
for 1..3 {
state $var = 1;
print $var++
}
}
test();test();
and
sub test {
my $a;
for 1..3 {
do_something_with($a);
state $var = 1;
print $var++
}
}
test();test();
would print different results.
But actually I would prefer if state somehow could be made to work other
way, even if closure isn't cloned. I mean, first variant, mentioned at top
of the message. Then we could use state vars in things like:
# I know that _this_ particular task could be solved better
# I'm not good in examplification.
%hash = map {state $k=1; $_ = $k++ } @array;
and always get our keys numbered from 1. And one still get behaviour(2) if
state declaration is at start of subroutine.
(Hmm, but I can't figure if it is possible )
This applies to FIRST {...} blocks too.
for 1..10 {
for 1..3 {
FIRST {...}
...
}
}
I'd expect that FIRST would be fired 10 times, not only once, because
FIRST looks here just as a mere funny loop control structure.
and of course I don't want it to happen once here, and 10 times there,
depending on such a subtle thing as appearance of outer lexical variables
in inner block. hmm.. but I don't want unnecessary cloning either, if it'd
slow down my program. I have a cake, please show me where to bite:)
Re: state vs my
On Fri, Dec 03, 2004 at 11:36:02PM -0800, Brent 'Dax' Royal-Gordon wrote: : Larry Wall [EMAIL PROTECTED] wrote: : So optimizing to a state variable won't necessarily help your loop : overhead, but it could help your subroutine overhead, at least in Perl : 5, if Perl 5 had state variables. Best you can do in Perl 5 is an : our variable with an obscure name. : : my $x if 0; : : I know it's *going* away, but it hasn't *gone* away yet. That doesn't really suppress reallocation, merely reinitialization to undef, since Perl never deallocates a pad once it's allocated. But yes, it's equivalent to an our variable in its lifetime. Might be a little faster or slower to access depending on the CPU architecture. Larry
Re: state vs my
On Fri, 3 Dec 2004 21:25:39 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sat, Dec 04, 2004 at 06:31:35AM +0300, Alexey Trofimenko wrote:
:
: for 1..10_000_000 {
: my ($a,$b,$c) = ...
: ...
: }
:
: vs.
:
: for 1..10_000_000 {
: state ($a,$b,$c) = ...
: ...
: }
:
: latter looks like it would run faster, because no reallocation envolved
: here.
Er, how did you try a state variable in Perl 5? It doesn't have state
variables...
I've emulated state vars like this:
instead of
for (...) {
my $a = ...;
...
}
i've written:
{ my $a;
for (...) {
$a = ...;
...
}
}
I think, effect is the same, (of course only if state vars declared at the
top of the block)
(second variant IS faster in perl5. slightly:)
perl timeit { my $a; for (1..10_000_000) { $a=10 } }
3.149s
perl timeit { for (1..10_000_000) { my $a=10 } }
4.709s
)
P.S.
btw, what about
my @rray;
# i'm starting to like that sigil is a part of name idea :)
for 1..10 {
{
push @rray, \( state $calar )
}
}
say @rray[0] == @rray[1]
what is the scope of state vars exactly? Common sense tells me that it
should be exactly the same as i've shown in second snippet above.. and
latter snippet would say undef.. so Cstate is just a syntactic sugar for
Cmy, which also allow us to remove redundant outer block. is it?
P.P.S. ah, offtopic. I've forgot, are bare self executing blocks outlawed
now? we have an ambiguity otherwise:
sub test {
...
{ #some bare block
...
}
}
looks like test() could return that block as closure in scalar context,
but would execute it immediately in void. wow:)
I should reread apocalypses, definitely..
Perl 5 already stores all the lexicals in the pad for the entire
subroutine. There is no separate pad for the inside of the loop.
Any differences in performance would be related to the actual
reinitialization of the lexical, not allocation.
hmm.. looks like heavy magic is involved here. Because perl5 makes a
feeling that every _block_ has it's own lexical pad. so, does it mean that
my $vars deallocated only on exit from surrounding subroutine, not from
nearest surrounding block? my experience show opposite, but I could be
wrong..
(or I just misunderstood conception of lexical pads)
Re: state vs my
On Sat, Dec 04, 2004 at 08:03:45PM +0300, Alexey Trofimenko wrote:
: P.S.
: btw, what about
:
: my @rray;
: # i'm starting to like that sigil is a part of name idea :)
Too cute. But what about %ash and unction? Or is it ubroutine? losure?
: for 1..10 {
: {
:push @rray, \( state $calar )
: }
: }
:
: say @rray[0] == @rray[1]
:
: what is the scope of state vars exactly? Common sense tells me that it
: should be exactly the same as i've shown in second snippet above.. and
: latter snippet would say undef.. so Cstate is just a syntactic sugar for
: Cmy, which also allow us to remove redundant outer block. is it?
No, it's not syntactic sugar for a Cmy. It's semantic sugar for
an Cour. The semantic sugar is that, while Cour is a lexically
scoped alias to a global, permanent package variable, Cstate is a
lexically scoped alias to a unique, permanent, anonymous variable.
You could implement Cstate using Cour with an autogenerated and
hidden package variable name, for instance.
If Cstate were based on Cmy, it would lose its value when you exited
the current routine. The whole point of a Cstate variable is that it
never loses its state regardless of the control flow.
In general, any Cstate declaration refers to a single, permanent storage
location. I say in general, because if you clone a closure, you get a
separate state location for each clone, in which case a single Cstate
declaration represents multiple states. In that sense it's a little
more like Cmy than Cour.
: P.P.S. ah, offtopic. I've forgot, are bare self executing blocks outlawed
: now? we have an ambiguity otherwise:
: sub test {
: ...
: { #some bare block
: ...
: }
: }
:
: looks like test() could return that block as closure in scalar context,
: but would execute it immediately in void. wow:)
: I should reread apocalypses, definitely..
You have to say Creturn {...} or some such if you want to return
a closure.
: Perl 5 already stores all the lexicals in the pad for the entire
: subroutine. There is no separate pad for the inside of the loop.
: Any differences in performance would be related to the actual
: reinitialization of the lexical, not allocation.
:
: hmm.. looks like heavy magic is involved here. Because perl5 makes a
: feeling that every _block_ has it's own lexical pad. so, does it mean that
: my $vars deallocated only on exit from surrounding subroutine, not from
: nearest surrounding block? my experience show opposite, but I could be
: wrong..
: (or I just misunderstood conception of lexical pads)
It looks like every block has its own lexical pad because entries
in the sub's pad are tagged with the range of statements over which
the declaration is valid. But Cmy $vars is *not*, repeat *not*,
deallocated on exit from the subroutine. Only the variable's
*contents* are deallocated (and that only if there's no external
reference generated to the data). If you call a function recursively,
it generates a new pad for each recursion level. On exit, that stack
of pads is *not* deallocated, on the assumption that if you called a
function recursively once, you're likely to do it again, and why do
all that work again?
It's kinda funny to watch the Parrot folks reinventing a similar scheme.
(Er, no pun intended. Really!)
Larry
Re: state vs my
On Sat, 4 Dec 2004 11:33:10 -0800, Larry Wall [EMAIL PROTECTED] wrote:
On Sat, Dec 04, 2004 at 08:03:45PM +0300, Alexey Trofimenko wrote:
: P.S.
: btw, what about
:
: my @rray;
: # i'm starting to like that sigil is a part of name idea :)
: for 1..10 {
: {
:push @rray, \( state $calar )
: }
: }
:
: say @rray[0] == @rray[1]
still your answer doesn't make it clearer. would this print 1 or undef?
I assumed it would say undef, but you said that state vars are reallocated
only on function cloning, whatever it is.. so state vars are owned by
functions, not bare blocks. If so, then it DOES print 1, doesn't it?
ah, that was a bad example, I can see now..
I thought, its primary use is for closures:
sub test {
my $a=10;
return sub { $a++ }
}
vs
sub test {
return sub {state $a=10; $a++ }
}
$func1 = test;
$func2 = test;
would closures in $func1 and $func2 share the SAME $a?
or is it that function cloning you said?
oh! that it. I've found example which could make it clear to me
sub test {
return sub {
for 1..3 {
state $var = 1;
print $var++
}
}
}
$a = test; $a() for 1..3; print ';'
$b = test; $b() for 1..3;
that could print, for different possible definitions of state:
1) 123123123;123123123
2) 123456789;123456789
3) 123456789;101112131415161718
looks like you meant third(!) variant.. but it doesn't make any sense for
me.
Re: state vs my
On Sun, Dec 05, 2004 at 02:15:51AM +0300, Alexey Trofimenko wrote:
: I thought, its primary use is for closures:
:
: sub test {
: my $a=10;
: return sub { $a++ }
: }
:
: vs
: sub test {
: return sub {state $a=10; $a++ }
: }
:
: $func1 = test;
: $func2 = test;
:
: would closures in $func1 and $func2 share the SAME $a?
No, they're separate.
: or is it that function cloning you said?
Yes, except it'd be better to call it closure cloning.
: oh! that it. I've found example which could make it clear to me
:
: sub test {
: return sub {
: for 1..3 {
:state $var = 1;
:print $var++
: }
: }
: }
:
: $a = test; $a() for 1..3; print ';'
: $b = test; $b() for 1..3;
:
: that could print, for different possible definitions of state:
: 1) 123123123;123123123
: 2) 123456789;123456789
: 3) 123456789;101112131415161718
:
: looks like you meant third(!) variant.. but it doesn't make any sense for
: me.
I don't know how you even get the third variant. I think it should be 2,
though I see how you'd get 1 if you think a loop clones every time through.
Certainly that one doesn't, since it doesn't refer to any external lexicals.
Perhaps statehood should be limited to official subs just like return is.
Larry
state vs my
for 1..10_000_000 {
my ($a,$b,$c) = ...
...
}
vs.
for 1..10_000_000 {
state ($a,$b,$c) = ...
...
}
latter looks like it would run faster, because no reallocation envolved
here.
I've read an advice somewhat like that in Ruby docs, tried it on perl5,
and it really makes a difference, especially on very short loops.
could it be done some tricky optimisation, so if some variable in loop
isn't going to have references on it, stored somewhere outside the block,
than Cmy before it will be changed to Cstate?
Re: state vs my
On Sat, Dec 04, 2004 at 06:31:35AM +0300, Alexey Trofimenko wrote:
:
: for 1..10_000_000 {
: my ($a,$b,$c) = ...
: ...
: }
:
: vs.
:
: for 1..10_000_000 {
: state ($a,$b,$c) = ...
: ...
: }
:
: latter looks like it would run faster, because no reallocation envolved
: here.
No reassignment either, since assignment to a state declaration only
happens at first time. If you expect $a, $b, and $c to get new values
each time through the loop, you'll be disappointed.
: I've read an advice somewhat like that in Ruby docs, tried it on perl5,
: and it really makes a difference, especially on very short loops.
: could it be done some tricky optimisation, so if some variable in loop
: isn't going to have references on it, stored somewhere outside the block,
: than Cmy before it will be changed to Cstate?
Er, how did you try a state variable in Perl 5? It doesn't have state
variables...
Perl 5 already stores all the lexicals in the pad for the entire
subroutine. There is no separate pad for the inside of the loop.
Any differences in performance would be related to the actual
reinitialization of the lexical, not allocation.
So optimizing to a state variable won't necessarily help your loop
overhead, but it could help your subroutine overhead, at least in Perl
5, if Perl 5 had state variables. Best you can do in Perl 5 is an
our variable with an obscure name.
Larry
Re: state vs my
Larry Wall [EMAIL PROTECTED] wrote: So optimizing to a state variable won't necessarily help your loop overhead, but it could help your subroutine overhead, at least in Perl 5, if Perl 5 had state variables. Best you can do in Perl 5 is an our variable with an obscure name. my $x if 0; I know it's *going* away, but it hasn't *gone* away yet. -- Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] Perl and Parrot hacker I might be an idiot, but not a stupid one. --c.l.p.misc (name omitted to protect the foolish)
