Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Re^4: RFC: Inline::Blocks or inline as a keyword?

by shmem (Chancellor)
on Jul 30, 2018 at 22:35 UTC ( #1219520=note: print w/replies, xml ) Need Help??

in reply to Re^3: RFC: Inline::Blocks or inline as a keyword?
in thread RFC: Inline::Blocks or inline as a keyword?

Thanks for clarifying, and apologies for my misunderstanding, which stems from:
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); }
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); }

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.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^5: RFC: Inline::Blocks or inline as a keyword?
by tobyink (Canon) on Jul 31, 2018 at 07:49 UTC

    Keyword::Declare isn't a source filter in the usual sense. Rather than pre-process the source before Perl parses it, it installs hooks into the Perl parser so that your custom parsing routines can be called when Perl encounters a new keyword you've defined. In general, this is definitely a better approach than source filtering.

    That said, I don't think it would work for your particular case because you want the ability to parse a normal-looking sub call specially (inline it) depending on how the sub had been declared (with the inline prefix) elsewhere in the file. In that case there's no keyword to hook into.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1219520]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (5)
As of 2020-02-17 10:15 GMT
Find Nodes?
    Voting Booth?
    What numbers are you going to focus on primarily in 2020?

    Results (71 votes). Check out past polls.