in reply to Re: Devel::Declare is deprecated, what’s instead? (Keyword::Simple)
in thread Devel::Declare is deprecated, what’s instead?

In perlapi, the description of KEYWORD_PLUGIN_EXPR implies the pluggable keyword API can support keywords in the middle of an expression. Unfortunately, Keyword::Simple (and modules that use it) doesn't support that. I'm not sure whether Keyword::API supports that.

  • Comment on Re^2: Devel::Declare is deprecated, what’s instead? (Keyword::Simple)
  • Download Code

Replies are listed 'Best First'.
Re^3: Devel::Declare is deprecated, what’s instead? (Keyword::Simple)
by LanX (Archbishop) on Aug 02, 2018 at 23:42 UTC
    I spoke to Lukas - aka "Mauke" - the author of Keyword::Simple in person at various conferences about this and macros in general.

    He said that it's pluggable keys which is not supporting it, and that he thinks that it's due to a bug in the implementation. I'm sure he would love to support it if possible. IIRC he even mentioned a discussion on P5P.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

      That's interesting, thank you. I tried to hack Keyword::Simple to return _EXPR, but that expectedly fails because it also creates a single OP_NULL as a statement returned, and that doesn't fly in the expression context. Also, I checked XS::APItest::KeywordRPN that is mentioned in the docs as a reference implementation of a keyword handler, and although it's broken now, it uses _EXPR that supposedly worked at least on 5.13.

      But that leads to another question: I wonder how one compiles perl code to get a optree? If it exists, then Keyword::Simple would be relatively simple to expand, I guess.

        From PL_keyword_plugin, an opcode tree must always be generated. Whatever code is generated, even a single no-op, perl should resume parsing the (possibly modified) code remaining in the source stream.

        In the example in Keyword::Simple, the provided keyword was consumed by the parser and the keyword handler called. The handler "stuffed" if in front of the current content of the source stream, "generated" a no-op then returned KEYWORD_PLUGIN_STMT, leaving the rest of the statement for perl to finish parsing.

        For a keyword in an expression, a similar series of steps should also work.

        In the case of XS::APItest::KeywordRPN*, the handler would have had to parse the expression itself, consuming the expression. At that point, the handler could have either generated an op-code tree for the parsed expression, or stuffed the source stream with an equivalent expression that perl could parse and generated a no-op.

        In theory, a no-op should no have effect (other than consuming time), even in the middle of an expression. When XS::APItest::KeywordRPN was working, it may be that it was generating an actual op-code tree for the RPN expression. In which case, that could be what's necessary to implement an "expression keyword". If it regenerated the expression for perl to parse, then probably something changed in the Plug-able Keyword API that XS::APItest::KeywordRPN was never updated to comply with.


        * Other than downloading the source distribution for perl (which I have no inclination to do), I have not found the XS source for XS::APItest::KeywordRPN, so I can only theorize on how it worked.