prj has asked for the wisdom of the Perl Monks concerning the following question:

I have a lot of code that uses Sub::Curried, which implements a "curry" keyword. Since it predates the custom keyword feature added in Perl 5.12, it uses Devel::Declare and Devel::BeginLift. But Devel::BeginLift uses some Perl internals in its XS code and doesn't build with recent versions. I made some changes based on total guesswork and got it to compile, but it doesn't pass its tests. Are there any guides to working with opcodes? As another approach, I also tried starting from scratch with Keyword::Simple, Keyword::Declare, or Keyword::Pluggable. But ::Simple and ::Declare can only implement statement-like keywords, while the "curry" keyword is supposed to be like "sub": it's used as a statement in the case of a named sub, or as an expression for an anonymous sub. Keyword::Pluggable can define expression-like keywords, but it expects any particular keyword to be always expression-like or always statement-like. It can't handle one keyword used both ways. Are there other modules that can define keywords with this flexibility?
  • Comment on updating Devel::BeginLift (or, statement vs. expression keywords)

Replies are listed 'Best First'.
Re: updating Devel::BeginLift (or, statement vs. expression keywords)
by LanX (Saint) on Jun 14, 2024 at 00:31 UTC
    > Are there other modules that can define keywords with this flexibility?

    Not that I'm aware of. The limitation of Keyword::Simple to statements is a major headache to many projects.

    > I also tried starting from scratch with Keyword::Simple,

    This would have been my suggestion, but you'll need to patch all code with a curry expression with a surrounding do {...}

    I only had a brief look into Sub::Curried but it seems to me that the "composition" features won't make it easier.

    Personally I think it would have been better to design all this with syntax of function attributes like :curry

    But going this way won't save you from refactoring your code.

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

[reply]
[d/l]
[select]

      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?

[reply]

        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.

[reply]
        > 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.

[reply]
Re: updating Devel::BeginLift (or, statement vs. expression keywords)
by etj (Priest) on Sep 22, 2024 at 16:25 UTC
    Note from THE FUTURE: "Paul Jarc" (using my powers of deduction, probably prj) has released a new Sub::Curried which switches away from using the two older distros. Nice work!
[reply]

Back to Seekers of Perl Wisdom