On 6/12/05, Dave Mitchell <[EMAIL PROTECTED]> wrote:
> You may be using slow evals, but other fast code may not be. Should the
> closure in
>
> sub foo { my $x = 1; return sub { 1 } }
>
> also capture the current instance of $x? You are basically condeming any
> code that creates any closure, however simple, to basically hang on to
> just about any data that has ever existed, in the vague hope that maybe,
> just maybe, some day some code may use an eval and make use of that data.
A simple analysis of the parse tree should show that sub { 1 } isn't
going to access $x. I personally don't see what's wrong with marking
certain constructs (eval, symbolic dereference, stash access, etc.) as
"dirty" and forcing a closure to close over everything if one is
present. This is optimizer stuff, really, in the same class of
problems as optimizing Parrot's continuation-based sub calls into
bsr/ret where possible.
Hmm...maybe the answer is that most destruction isn't guaranteed to be
timely, and any object which *is* guaranteed to have timely
destruction is illegal to close over unless the programmer marks it as
okay. Or maybe that's only with an appropriate stricture...
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
