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

Re: Do we want a CXt_CUSTOM?

Thread Previous | Thread Next
Chad Granum
February 5, 2021 23:33
Re: Do we want a CXt_CUSTOM?
Message ID:
+1  I have yet to convert some of my old keyword things from
Devel::Declare. I would like to do it. Things that make custom keywords
easier are sorely needed. I suspect if this was added I would use it.

On Wed, Feb 3, 2021 at 2:56 PM Paul "LeoNerd" Evans <>

> I have now implemented a number of custom keyword modules on CPAN:
>   * Future::AsyncAwait
>   * Object::Pad
>   * Syntax::Keyword::Dynamically
>   * Syntax::Keyword::Finally
>   * Syntax::Keyword::Try
> Of these, the latter two (will or already) have some quite complex
> internals in order to deal with subtle interactions between their added
> semantics and parts of internal perl core - most notably around the
> effects of `return` or `next/last/redo` from within their added
> structures.
> I found while I was reïmplementing try/catch and (separately) FINALLY as
> native perl syntax this part was in fact much easier than the CPAN
> module version, because I was able to add new context-stack types (or
> at least change semantics of existing ones). This isn't something that
> CPAN modules can currently do.
> Under the present implementation, the context stack type itself is
> stored in a 4 bit value; whose upper 4 bits contain various flags.
> Values 0 to 12 are already defined by core, so we have just three
> possible types remaining at present. It looks fairly likely that I
> shall need one of these for FINALLY, and depending on what makes sense
> to implement try/catch might need one too, or it might be able to share
> with eval {}.
> In order to reserve space, give us a possible escape hatch in the
> future, and also to make more things like this sort of experimentation
> possible via CPAN modules, I would like to propose adding a CXt_CUSTOM
> type as number 15 (leaving space for two more still).
> I don't have an exact design yet, but I feel that something involving a
> hook function registered with it at the time it is pushed to the scope
> stack would work. This function is then invoked later on at the time
> that various operations are trying to unwind the stack, and would be
> passed in details of the reason why the stack is being unwound.
> I'm fairly sure that if such had existed before I made
> Syntax::Keyword::{Try,Finally} then it would have been much easier to
> implement those two things. (Though it is the hindsight of having to
> cope without them that has lead me to think up the design).
> How do we feel about this one? Should I create it?
> --
> Paul "LeoNerd" Evans
>      |
>  |

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