*Thank goodness no one uses JSON to encode a language (in the way that ant uses ...

11ren · on Jan 13, 2009

If Javascript used JSON in the way I described, it would look something like this (view page source for original):

  {
    "function": {
       "signature": {
         "name": "byId",
         "args": ["id"]
       }
       "body": {
         "return": {
           "call": {
             "target": "document",
             "method": "getElementById",
             "args": ["id"]
        }}}
  }}

gruseom · on Jan 13, 2009

Yeah, I know you meant that. The point is people don't do it because they don't have to. In XML, by contrast, your example has been written countless times. For a few years it was almost de rigeur.

JS's notation for data and code may not be identical, but they're close enough to get things done (that's JS's Lisp heritage showing). Since XML was explicitly designed to prevent people from doing a bunch of things they needed, it's not surprising that what resulted were montrosities.

I suspect that XML is a manifestation of the kind of people who like to lock things down and specify them up front, until they're so tied up in knots of their own making that they form a committee to design the same thing all over again. As you may guess, I'm of the opposite camp. Happily, I can work in my medium and leave them to theirs.

ynniv · on Jan 13, 2009

Lets assume that an identifier array that starts with the word "function" is a function declaration, and has the additional place arguments name, argList, and body. Now we get something like this:

[ "function", "byId", ["id"], [ "call", "document", "getElementById", ["id"] ] ]

11ren · on Jan 14, 2009

Yeah, I was thinking that. You're also omitting an explicit return, I would guess by assuming the value of the last statement (as an expression) is to be returned (this won't work in general, because Javascript allows multiple returns, like C or Java). It's closer to a lisp syntax, by using nested lists instead of structs/maps. I submit that it's against the spirit of JSON to be able to name the values, and then not use that ability. I think you're Greenspunning it ;-). Sure is shorter though. :-)

ynniv · on Jan 15, 2009

I could include multiple statements and allow returns like this:

["function", "byId", ["id"], [["return" ["call", "document", "getElementById", ["id"]]]]]

(basically lisp syntax substituting JS array notation.) My point is that JSON is capable of being terse, and XML is not. XML attributes are unordered, so you have to use child nodes, which have to be named. The best you could do is:

Which is significantly longer than a positional JSON serialization. XML is also harder to implement a parser for, and existing libraries tend to be difficult to use (python etree and ruby's implementations are a much better direction). Now, someone else's raw XML is often easy to understand, whereas my array based JSON format would clearly require domain knowledge. Because of this, I prefer JSON for small network requests that are consumed by scripting languages.

For larger, disk files, the overhead of XML is marginalized, and the extra formatting might help in hand editing and error correction.

As for Greenspunning, I think its a perspective issue. The example was one of code serialization, so the lisp syntax is particularly well suited to the problem. Programmers also have the domain knowledge, so the less verbose format is still easy to understand.

fizx · on Jan 13, 2009

I see what you're saying. But I use json to encode my latest language (release in the coming week). But its a really limited case. It would suck in the general case, but its not always terrible (I hope). Just sayin.

gruseom · on Jan 13, 2009

Exceptions are welcome :) But why are you doing this? Just curious.

Actually, in my current project we use JSON to encode parse trees. It's no s-expressions, but it works pretty well.

fizx · on Jan 13, 2009

Its an embedded language for xml/html data extraction/scraping. It's inspired by MQL ( http://www.freebase.com/tools/queryeditor/ , look for the examples link towards the bottom), which should give you an idea of how json can be used to represent structure.

The Ruby and Python bindings let you choose between JSON and the native hash/array or list/dictionary structures. You can be idiomatic and portable at the same time.

11ren · on Jan 14, 2009

That's very cool. JSON seems a natural conceptual match for querying data like that. I think a different concrete syntax might be more readable for me - but could just be my unfamiliarity. And JSON is an instant, no-work solution, so there's no downside. It would be good to see your project.