Source filtering? No!

Since - in what way is Keyword::Declare not a source filter? From the description of that module (emphasis mine):

At compile time, when the parser subsequently encounters source code such as:

loop 10 {
    $cmd = readline;
    last if valid_cmd($cmd);
}
[download]

then the keyword's $count parameter would be assigned the value "10" and its $code parameter would be assigned the value "{\n$cmd = readline;\nlast if valid_cmd($cmd);\n}". Then the "body" of the keyword definition would be executed and its return value would be used as the replacement source code:

for (1..10) {
    $cmd = readline;
    last if valid_cmd($cmd);
}
[download]

Skimming that module, I get the impression that it is definitely a source filtering module. It is not a general purpose macro module. It is not a module for inlining subroutine bodies at the calling places as do blocks. It implements a "domain-specific language" (this might be the wrong term, beat me to death for it please) to extend Perl with arbitrary keywords. Right?

That's all ok, and I admire Damian's genius.

But the purpose of this meditation was not about "the right way to implement" inlining, but rather asking (see title) - should we have an inline keyword, or have a module for that. The attached module is a POC, a thinly veiled attempt to get approval and XP, and something which just does what it claims to do, nothing else.

Had there been written instead

A more robust way to implement your module is Keyword::Declare, since (arguments here)

no misunderstanding would have arisen. Instead in the follow-up I read

I wanted to express that the Keyword::Declare module is the tool you need to implement your module without source filters or rolling your own perl parsing regexes.

which induces violence phantasies in me and, at the same time, drops me into utter resignation. Gosh, what a shitty job did I do. No wonder, cuz there will always be someone brighter than me, and they can annihilate my efforts with just one fell stroke of genius. Then there is the the tool you need to implement your module which, as so often, means "do as I say, but I won't tell you how." And it sounds so pythonesque. There's one way. Leaving away the "source filters" part, since that was discussed above.

I'm so fed up with, and consider harmful, such advises as

Q: How can I match IPv4 addresses reliably? I use /\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}/
A: Don't. use Regexp::Common

without at least saying "if you want to know what else you have to check, read the source" or at least saying that 377 isn't a valid dotted quad component and why.

So, somebody please (if it is worth the effort) implement this module in a more robust fashion using Keyword::Declare.

Lastly, to address the rolling your own perl parsing regexes - yeah, that's the right way to go, don't roll your own, blame somebody else. In one of my first posts here I answered to don't re-invent the wheel with "I don't want to reinvent the wheel, I just want a wheel with no car around just in case I want to build a nifty chopper".

No more choppers, I'm tired of it all. Bye.