Re^4: Devel::Declare is deprecated, what’s instead? (Keyword::Simple)

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

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.

Comment on Re^4: Devel::Declare is deprecated, what’s instead? (Keyword::Simple)

Replies are listed 'Best First'.
Re^5: Devel::Declare is deprecated, what’s instead? (Keyword::Simple) by RonW (Parson) on Aug 06, 2018 at 20:33 UTC
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.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Devel::Declare is deprecated, what’s instead? (Keyword::Simple)
by RonW (Parson) on Aug 06, 2018 at 20:33 UTC

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.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom