develooper Front page | perl.perl5.porters | Postings from April 2012

Re: [perl #24250] "return" required in some anonymous closures

April 20, 2012 05:01
Re: [perl #24250] "return" required in some anonymous closures
Message ID:
Nicholas Clark wrote:
>                   The bug (#24250) is that that perception code isn't 100%

Oh really, I didn't realise there was any attempt for it to be seriously

With PadWalker and suchlike, it's impossible for it to be certain about
a positive (no modification).  Also, by virtue of the halting problem,
it's impossible for it to be certain about a negative.  You can discount
PadWalker and the like, and potentially get something that has no false
positives and a useful proportion of true positives when applied to
the purest kind of pure Perl code.  But that's rather a lot of work,
for a dubious payoff.

>Also, assuming that it could be made 100% accurate, as the inlining is
>supposed to be an optimisation, is there any way it user code can spot
>the difference between doing it and not doing it, other than introspecting
>the optree, or benchmarking something?

By definition, if an optimisation is done correctly then you can't tell
the difference short of such means.

>What does this generator give us, that putting references-to-constants in
>the symbol table doesn't already give us?

It gets you the constant-value sub as a sub, in isolation.  It avoids
the need to touch a stash, which may not be where you want the sub to
end up and is a rather indirect way of getting the actual sub object.
(Maybe you want to feed the sub to Lexical::Sub.)  It would also be an
explicitly supported interface, unlike direct stash modification.

[variant call checker]
>Does this reduce complexity?

Don't know yet.  Probably leaves it about the same overall.  That's why
I don't have any clear idea yet of whether it ought to be done.

-zefram Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About