Add a PPC for "-j" perlrun option

[catouc]

trafficstars

This proposes a new perlrun option flag that handles JSON input.

[leonerd]

99% sure this could be implemented as a CPAN module. You could then alias something like

alias jperl = perl -MPerlUseJSONAsStdin

and use that instead.

[guest20]

@leonerd Would PerlUseJSONAsStdin be some kind of source filter?

[leonerd]

@leonerd Would PerlUseJSONAsStdin be [some kind of source filter]

I doubt it because source filters are extremely fragile and prone to breakage, and not a robust way to implement language-level things.

[catouc]

99% sure this could be implemented as a CPAN module.

I feel like that is missing the original intention of having JSON aware handling in the actual Perl runtime so we do not have to work with getting external modules into hard to get to systems where Perl is already prevalent.

[kfly8]

Sorry for jumping in with a suggestion out of the blue.

Would you consider taking a look at the following module?

https://metacpan.org/pod/ARGV::JSON

• It allows you to handle JSON in a one-liner: perl -MARGV::JSON -anl -E 'say $_->{foo}->{bar}' a.json
• Also, ARGV::JSON is a small module that only relies on core modules (except for the JSON module). So even in an environment where we can’t install it, we could still take inspiration from the code and implement something similar.

[tonycoz]

@leonerd Would PerlUseJSONAsStdin be [some kind of source filter]

I doubt it because source filters are extremely fragile and prone to breakage, and not a robust way to implement language-level things.

The source filter in this case just added a prefix and suffix to the supplied code, no different to what -npa and the OP's suggested -j solution does.

The only other way I see to do this on CPAN would be to hack on the PL_main_cv optree

[esabol]

I don't think https://metacpan.org/pod/ARGV::JSON is using a source filter, is it? It seems to work well. Does it do what @catouc wants?

[tonycoz]

I don't think https://metacpan.org/pod/ARGV::JSON is using a source filter, is it? It seems to work well. Does it do what @catouc wants?

The source filter was referenced by the link in the comment I quoted, but got unlinked

[bulk88]

I see a different problem with what this PPC does, its not about the cmd line arg flag this PPC creates, but something else the PPC createds.

This PPC "standardized" or "best-practices" or basically is writing a .pdf issued by IEEE Working Group 0x5065726C35 saying disk file JSON::PP.pm is the one and only official and authorized JSON parser for the Perl ecosystem, and therefore the one and only authorized JSON parser for the Perl 5 language for corporate business code. JSON_PP.pm adds 1-2 seconds of CPU time to every perl Makefile.PL execution vs Cp::JSON:XS. The only reason why P5P even distributes JSON_PP.pm in its .git is because the permutation of miniperl.exe and EU::MM require it, which will NEVER EVER again exist once the end user has a perl.exe or libperl.so.dll file on their disk,

So I believe, if perl.exe -j becomes a feature, it requires shipping the CP::J:XS module insider P5P .git, or static linking a neutered (meaning stripped in a *sub{CODE} style) version of CP::J:XS's C code inside libperl.so/.dll, or atleast shipping a full blown full featured unmodified CP::J:XS .xs/.so/.dll with core.

CPAN's version.xs/version.tar.gz is already shipped by P5P in-core inside libperl.so.dll in a neutered way that miniperl.exe can use without a functioning EU::PXS.pm and without a functioning EU::MM.pm.

I see little reason why a .git/regen/jsonxs.pl can't automatically create a feature stripped version of CP::J:XS and static link it into libperl.so.dll. A big benefit is saving alot of CPU and wall time in building blead perl and make self-testing it.

[haarg]

I don't see any reason why this PPC would permanently require JSON::PP if a faster parser became available in core in the future.

[guest20]

@haarg you mean to say that software can be changed after somebody merges it? my word!

[Leont]

@haarg you mean to say that software can be changed after somebody merges it? my word!

He means the PPC shouldn't mention an implementation detail like that, it should describe only the behavior.

[catouc]

He means the PPC shouldn't mention an implementation detail like that, it should describe only the behavior.

If that is something we deeply care about we can remove the mention an replace it with "JSON parser in Perl". Using JSON::PP basically just disambiguates what that parser would be. But I am happy to change the wording if required/desired.

Just to reiterate the rejected ideas section of this proposal, the point is not to have to find a module on CPAN or a source filter. The point is to have this built-in so it is available in environments where installing stuff from the outside is tedious but Perl being ever present would alleviate this problem by offering nicer log parsing capabilities. In some way it ends up being similar to -F since it also just deals with parsing specific formats, we're just taking one of the most used formats on the planet right now and offer a bit more convenience.

If there's actual thoughts about the usability or feedback on how this feature itself could be improved that would be much appreciated :)