develooper Front page | perl.perl5.porters | Postings from February 2003

Re: [PATCH] jumbo closure fix

Thread Previous | Thread Next
From:
Gurusamy Sarathy
Date:
February 26, 2003 11:03
Subject:
Re: [PATCH] jumbo closure fix
Message ID:
200302261903.h1QJ3IB21196@smtp3.ActiveState.com
On Wed, 26 Feb 2003 14:49:47 GMT, Dave Mitchell wrote:
>This patch fixes all the major outstanding closure bugs that I am aware
>of (well, apart from ones pertaining to /(?{...})/ ).
>I've achieved this by completely rewriting pad_findlex() from scratch,
>so effectively re-implementing closures from a blank sheet.
>
>The most notable differences are.
>
>* named subs now close on behalf of inner subs; eg the following now
>prints 1 rather than undef:
>
>    {
>	my $x = 1;
>	sub f { sub { print $x }->() }
>    }
>    f();

Nice.

>* run-time cloning is now a lot faster, eg $a = sub {$x} is 15% faster,
>$a = sub {$x+$y} is 25% faster. This is because at compile time, the index
>into the parent pad is recorded for each outer lex, so cloning just
>involves grabbing each approriate value from the parent pad rather than
>calling pad_findlex() for each outer lex.

How does this interact with recursion?  It sounds like the behavior
may be significantly different now...

>* warnings are changed and more pervasive:
>
>the warning 'Variable \"%s\" may be unavailable' is now the more assertive
>'Variable \"%s\" is not available', and some cases that formerly caused
>this warning now cause 'Variable \"%s\" will not stay shared' instead, and
>vice versa. Several cases that formerly quietly did something strange
>(usually involving a mysterious shared undef value), now give the 'is not
>available' warning.

I never really liked the original warnings, so I'm not sure I like
escalating the frequency of them. :)

IMO, the original warnings are rather misguided, because they
ass_u_me a particular intent which may not be (in fact most
often isn't, given that most people aren't trying to do anything
fancy with closures) true.  It may be better to let these
variables resolve as normal and let "use strict" do its thing.

>* There's a new global variable PL_cv_has_eval, that gets set during
>compilation if any eval-like constucts are found within the CV's ops.

Not sure of the implications of this.  Does this set up
action-at-a-distance scenarios (in the sense that adding an
eval"" into a piece of code makes it suddenly behave differently)?

Or is it purely an optimization?

I hope code doesn't behave differently inside the debugger vs
outside it.

Excellent work, keep it up.


Sarathy
gsar@ActiveState.com

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About