Show HN: LJSON: JSON extended with pure functions

I think it&#x27;s a lovely idea, with an interesting implementation.<p>Obligatory HN style comment: It might be wise to strengthen the description from &quot;pure&quot; functions to &quot;pure and terminating&quot;. I&#x27;ve not had time to form an opinion on whether the restrictions are sufficient to ensure this (JavaScript&#x27;s evaluation rules are...complex). However, the informal specification of this being a lambda calculus with multiple arguments isn&#x27;t strong enough - that would allow non-termination on load, which is not something you really want in your data serialisation format.

Fun project. From examining the source code, they are using the technique that can be considered a kind of higher order abstract syntax (HOAS). In particular, LJSON can be fooled by so called exotic terms. E.g.<p><pre><code> LJSON.stringify(function(v) { return v; }) </code></pre> evaluates to the string<p><pre><code> (function(v0){return v0}) </code></pre> While<p><pre><code> LJSON.stringify(function(v) { return v(null) } ) </code></pre> Evaluates to the string<p><pre><code> (function(v0){return &quot;v0&quot;}) </code></pre> In the latter case, v(null) was able to examine the variable that stringify injects into the function. In this case, v(null) is the name of the injected variable.

Without being able to call pure functions within pure functions, what use is this beyond the trivial simple examples? Couldn&#x27;t it be possible to pass a &quot;this&quot; argument as the current JSON node and have it traverse the tree or something? For example:<p><pre><code> { &quot;math&quot;: { &quot;sin&quot;: function(x) {...} }, &quot;numerics&quot;: { &quot;sin2&quot;: function(x) { return this.parent.math.sin(x) }, &quot;parent&quot;: [automatically inserted by parser] } }</code></pre>

Neat concept.<p>It reminds me of how JSON started - as just a string representation of a javascript object and parsing JSON was as simple as evaling it.<p>Once it picked up steam, it got a formal definition and a parser.<p>If serializing pure functions ever takes off, it will have to follow the same route - without using clever javascript tricks to make it work.<p>Still, very cool concept.

This would be interesting, except JavaScript is a terrible language for this. At the minimum I think you&#x27;d want all the arguments and return values to be strictly typed. Otherwise you can&#x27;t for example determine how much memory to allocate for the returned value. The big strength of JSON is that the encoder and decoder can be written by anyone in any language fairly easily. I&#x27;ve used it in JS, Python, PHP, and C, and every time it&#x27;s been super easy because the format is so simple.<p>What would actually be cool is to add type hints to JSON. That way we could conceivably add things like date types to it fairly easily.

This is something I&#x27;d wanted to do, and I&#x27;m glad someone else had the same idea. Lots of exciting possibilities.<p>Something important that needs doing is strictly defining the JavaScript subset used. As simple as possible, ideally, in keeping with the JSON spirit. This would mean you could then safely implement that subset in other languages. Imagine serialising a PHP function into λJSON and running it from JavaScript, or vice-versa!

Neat idea, mutable in serialization format and functions...<p>We are a step close to the YAML fiasco that has crippled rails.<p>&#x2F;me grabs popcorns, and will likely enjoy to watch the world burns.

I definitely see some uses to it as a way to pass client code to the server safely. What would stop the client from using global variable though?