http://qs1969.pair.com?node_id=1058691


in reply to JSON parser as a single Perl Regex

With due respect, I admit that this hack is cool and a source of great learning experience for others.

However, I have to ask: what is the client's requirement, to be more exact? Prior to the time of this post, there had already been JSON::PP and Mojo::JSON (which became JSON::Tiny in Oct 2012) on CPAN. They are both faster than this regex version, already support Unicode, and I suspect have smaller footprint also. JSON::PP is also much preferable to me because it gives helpful error message instead of just returning undef or die-ing with 'no match'. You can just stick either in the project source repo and be done with it in a couple of minutes.

Replies are listed 'Best First'.
Re^2: JSON parser as a single Perl Regex
by davido (Cardinal) on Oct 19, 2013 at 06:34 UTC

    Prior to the time of this post there had already been JSON::PP and Mojo::JSON (which became JSON::Tiny in Oct2012)...

    I just want to clarify this: If you skim to the bottom of the POD for JSON::Tiny you will find this:

    ACKNOWLEDGEMENTS: ...to Randal Schwartz for showing the Los Angeles Perl Mongers (Sept 2012) his embeddable pure-regexp JSON parser, and explaining it on PerlMonks (995856). He wasn't involved in JSON::Tiny, but it was the exploration of alternatives to his solution that led to this fork of Mojolicious's JSON parser.

    JSON::Tiny wouldn't exist if it weren't for two things: First, for the work that Sebastian and his team did to bring us Mojo::JSON as a component of the Mojolicious framework. And second, if merlyn hadn't elevated my interest in the topic by presenting his pure-regexp solution at Los Angeles Perl Mongers in September 2012.

    I won't try to put words in his mouth or explain the rationale that he presented at LA-PM for the regexp monstrosity (or thing of beauty). My understanding was that he needed a light-weight JSON parser that he could embed in a $project. He was justifiably proud of the regular expression solution. And while it's certainly fewer lines of code than JSON::Tiny, I believed that there might be a more robust way to embed a pure-Perl JSON parser in a project.

    A few days later I found myself thinking about it again, and remembered that one of Mojolicious's philosophies is to minimize external dependencies. That meant that Mojo::JSON should be pretty easy to adapt to a stand-alone module. ...and after working around its use of Mojo::Base and Mojo::Utils, the conversion to a standalone module that could (if absolutely necessary) be copy/pasted right into a code base was straight-forward; JSON::Tiny came into existence.

    Mojo::JSON on its own wouldn't have worked for merlyn, because it relies on Mojo::Base and Mojo::Utils. I had to embed the functionality that Mojo::JSON needed from those two modules before JSON::Tiny could be made stand-alone. The test suite also required a bit of adaptation. The tests were almost all identical to their Mojo::JSON versions, but in JSON::Tiny the test suite had to emulate some of the support functionality that the Mojolicious framework would have provided.


    Dave

      Thanks for posting this.
Re^2: JSON parser as a single Perl Regex
by merlyn (Sage) on Oct 18, 2013 at 15:17 UTC
    Strangely enough, this project needed both YAML parsing and JSON parsing (don't ask!). I was able to cannibalize the YAML::Tiny, but I didn't find a similar module for JSON. I started writing a traditional recursive descent parser, and then I remembered that modern regex can do it all internally, so I took a whack at it. You see the result.

    -- Randal L. Schwartz, Perl hacker

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

      My point is, JSON::PP was perfectly cannibalizable at that point. But I understand that you probably thought it was a chance to do something cool.
        I've since looked at JSON::PP, and it's a lot more code. I like my approach better.

        -- Randal L. Schwartz, Perl hacker

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.