Perl Monk, Perl Meditation | |
PerlMonks |
Re^2: RFC: Inline::Blocks or inline as a keyword?by shmem (Chancellor) |
on Jul 30, 2018 at 15:05 UTC ( [id://1219491]=note: print w/replies, xml ) | Need Help?? |
Your benchmark is a little too simple. You'll notice the "plain" case and the "do" case run at the same speed. Of course, but there's that drop for the "do_vars" sub in which the arguments passed to a subroutine are assigned as lexicals inside the "do" block. In that case optimizing away the scope isn't possible, which of course happens with loading pragmas. Your module implementation is mostly good, but I don't like how you configure it with global variables. What if two modules by different authors try to alter $declmatch? It would be better to allow people to pass these as parameters to import. Thank you. - Indeed that's work to be done yet (and easy enough): making the package globals into package private lexicals as defaults, which can be overridden by named import parameters. This definitely makes more sense. update: done in the OP. You don't seem to do anything to cover the case where the inlined sub closes over variables which are declared later than when it is called. This is on purpose, because that would get me into trouble, into the egg vs. hen problem: I would need to check for outer frames and inspect the nature and existence of variables in those, which are used inside the inlined block. But only constants in closures are suitable for inlining, dynamic closures aren't. So I would need to compile the whole stuff first to munge the source after the fact... no. This module is purely for textual replacement, think cpp. As a related note, perl4 had the -P command line switch, which caused the source being run through cpp. When did that go away in perl 5? and why?
perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
In Section
Meditations
|
|