in reply to Re: updating Devel::BeginLift (or, statement vs. expression keywords)
in thread updating Devel::BeginLift (or, statement vs. expression keywords)

Thanks--yeah, if I were starting from scratch I'd probably do something like Attribute::Curried for the sake of a less fragile implementation. I do like Sub::Curried's composition operators, though, so I'd keep those. (Some of them are actually my own contribution.)

I might end up taking a stab at a more flexible keyword module myself. Got any pointers, besides perlapi and the source of the existing modules?

  • Comment on Re^2: updating Devel::BeginLift (or, statement vs. expression keywords)

Replies are listed 'Best First'.
Re^3: updating Devel::BeginLift (or, statement vs. expression keywords)
by hv (Prior) on Jun 14, 2024 at 14:43 UTC

    Definitely make contact with Paul Evans (PEVANS, leonerd): he wrote most of the keyword infrastructure, and as far as I understand it would like to bring it into perl core if/when he can get it to the right combination of stability and flexibility.

Re^3: updating Devel::BeginLift (or, statement vs. expression keywords)
by LanX (Saint) on Jun 14, 2024 at 10:45 UTC
    > Got any pointers, besides perlapi and the source of the existing modules?

    No sorry. *

    Combining attribute handlers and (moderate) source filters are my best bet in your case¹.

    They are old and stable.

    I'm not a big fan on building skyscrapers of code on more and more experimental modules to invent fancy syntax.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    see Wikisyntax for the Monastery

    *) I don't claim to know all internal hooks and possibilities!

    ¹) rescuing "a lot of code" with nonstandard syntax.