On 6/12/05, Dave Mitchell <davem@[...].com>  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 <brent@[...].com> 
Perl and Parrot hacker