Larry Wall wrote:
On Thu, Feb 02, 2006 at 12:51:36PM +0100, Leopold Toetsch wrote:
: Another idea:
:
: We keep the call frame of subs with statics (or Perl6 INIT and FIRST
: blocks) after returning from the sub. Additionally, we can set a new
: entrypoint for the sub after running the INIT code (or static
: initializer). The entrypoint would be reset for cloning closures to
: achieve perl6 FIRST block semantics.
Uh, maybe I'm pointing out something that's already blindingly obvious
to everyone else, but for "state" variables cloned closures can't
use the same static storage location. (Or is that what you're meaning
already by "keep the call frame"?)
Yep. With the scheme mentioned above a cloned closure would get a fresh
'state' variable as it of course needs distinct registers (aka call
frame) too.
: The draw backs are increased memory usage and it doesn't work together
: with recursive subroutines easily, albeit I don't know, if recursive
: subs with statics are really meaningful.
Unlike the situation with clones, a "state" variable *is* shared
between recursive invocations. As for whether that's meaningful,
I don't know either.
That's the same with a C static. Rescursion (not tail recursion) would
need some extra copying of state vars and book-keeping of register frames.
...But you could, say, temporize such a variable
just like a global, and that might make some kind of sense.
Yep.
... Anyway,
the P6 model of "state" is more like a persistent lexical than like
C's static.
Sorry for my dumb question - what's the difference then? (Besides that C
dosn't have closures ;)
... (Though of course Parrot will probably want C's static
semantics for various other languages...)
Anyway, I thought I'd clarify a bit--we just don't want people
confusing "state" with "static", given the similarity of the names.
Larry
leo
