develooper Front page | perl.perl5.porters | Postings from June 2010

Re: [PATCH] Compile-time hooks into lexical scoping

Thread Previous | Thread Next
Jesse Vincent
June 28, 2010 19:00
Re: [PATCH] Compile-time hooks into lexical scoping
Message ID:

On Mon 19.Apr'10 at 10:42:46 +0100, Ben Morrow wrote:
> The attached patches make it possible for extensions to hook into perl's
> lexical scope mechanism at compile time. This would allow things like my
> SCOPECHECK and Florian's @{^COMPILE_SCOPE_CONTAINER} to be implemented
> as CPAN modules[1]. Usage is like this (from XS):

So, this patcheset from April appears to have been warnocked. I'd love
to see some thumbs up or down about the implementation. In general, I'm 
in favor of any sort of hooks that allow CPAN modules to be evil/amazing
more safely, so long as they don't compromise performance, efficiency
or stability.


>     STATIC void my_start_hook(pTHX_ int full);
>     STATIC void my_pre_end_hook(pTHX_ OP **o);
>     STATIC void my_post_end_hook(pTHX_ OP **o);
>     STATIC void my_eval_hook(pTHX_ OP *const o);
>     STATIC BHK my_hooks;
>     BOOT:
>         BhkENTRY_set(&my_hooks, start, my_start_hook);
>         BhkENTRY_set(&my_hooks, pre_end, my_pre_end_hook);
>         BhkENTRY_set(&my_hooks, post_end, my_post_end_hook);
>         BhkENTRY_set(&my_hooks, eval, my_eval_hook);
>         Perl_blockhook_register(aTHX_ &my_hooks);
> This will cause
>     - my_start_hook to be called at the start of compiling every lexical
>       scope, with the 'full' parameter from Perl_block_start.
>     - my_pre_end_hook to be called at the end of compiling every lexical
>       scope, *before* the compile-time stack is unwound, with o pointing
>       to the root OP for the scope. It is a double pointer so the hook
>       can substitute a different OP if it needs to.
>     - my_post_end_hook to be called *after* the stack is unwound.
>     - my_eval_hook to be called just before compiling an
>       eval/do/require, with o set to the OP that requested the eval.
> The patches are rebased against current blead, and the branch has been
> pushed to . I hope
> including a whole lot of patches in one mail like this is OK: it seemed
> easier than separate mails for each patch, since they all go together.
> Ben
> [1] Implementing the rest of the Perl 6 blocks on CPAN would require at
> least one more patch, to allow extensions to create pad entries.

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