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 C<state> is just a syntactic sugar for
: C<my>, which also allow us to remove redundant outer block. is it?
No, it's not syntactic sugar for a C<my>. It's semantic sugar for
an C<our>. The semantic sugar is that, while C<our> is a lexically
scoped alias to a global, permanent package variable, C<state> is a
lexically scoped alias to a unique, permanent, anonymous variable.
You could implement C<state> using C<our> with an autogenerated and
hidden package variable name, for instance.
If C<state> were based on C<my>, it would lose its value when you exited
the current routine. The whole point of a C<state> variable is that it
never loses its state regardless of the control flow.
In general, any C<state> 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 C<state>
declaration represents multiple states. In that sense it's a little
more like C<my> than C<our>.
: 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 C<return {...}> 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 C<my $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
