See https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule

That 'half of Common Lisp' thing keeps popping everywhere, unless explicitly planned.

Ironically, I think common lisp is itself 'an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp'.

That is in fact Morris's Corollary to Greenspun's Tenth Rule.

It's JSON as AST!

Two things that bother me:

First, the insistence on changing the way keys are written so as to break compatibility with JSON.

Second, the assumption on the ordering of keys in an object--it's my understanding that the standard does not require the order of keys to be preserved. Even if everyone does it, that's not a good thing to force on people if they are otherwise following the official standard.

It is OK to build on the JSON standard and say that an order matters. It will make it more difficult to interoperate, though.

Dropping the requirement to double-quote key names completely abandons JSON, though.

And once you do that, it is not at all clear to me what the point of this is. If you can't parse it as JSON, you get no lift from JSON and you can't use any existing JSON-based code, so why then accept the constraints of JSON?

A specification that used completely standard JSON with no ordering in the keys would make a lot more sense to me.

Further, were I going to do that, if I cared about order, I would use the construct in JSON that indicates order. It seems to me the natural sexpr -> JSON conversion for

   (a b c (d e f))

would be

   ["a", "b", "c", ["d", "e", "f"]]

as thrysus says, with an option on

   [{"type": "quoted", "value": "x"}, "y", "z"]

for special quoting forms and such. Or the quoted goes around the whole list or whatever makes sense.

All things considered, this proposal would require much more work before it could be useful to anybody; right now it tries to straddle two worlds and isn't successful at either of them. And I'm afraid I don't just mean "it's not very good at either"... I don't think it successfully covers either one at all.

Without assuming order, you'd be forced to use something that explicitly provided order, such as an array. I suppose you could use

    { "jexpr":
        [ "function",
          "and",
          "its",
          [ "arguments",
            "may be",
            "arbitrarily complex"] ] }

Or better yet, how about something like:

   [ "jexpr",
      [ "function",
            "arg1",
            "arg2",
            ["Complex", "argument"]]]

Which wouldn't break the spec either. It also happens to pretty closely match an S-Expression.

If you made simple strings atoms and a "'triple quoted'" strings (or substrings) a string then you could implement a simple Lisp in it by replacing the parse() function in https://www.hackerschool.com/blog/21-little-lisp-interpreter.

Might be an interesting way to expose an api.

getting a 404 on the linked article about dsl's and linked expressions.

Edit: I believe this is the proper link: http://sriku.org/blog/2012/04/14/creating-dsls-in-javascript...

Definitely interesting though - json as a DSL with implementation in many languages could be useful for lots of message bus applications.

Yep, that's the proper link.

Disclaimer: I made the post in HN but (unfortunately) I'm not the blog author.

Just use s-expressions, already.

Especially if you're not even using real JSON.

An actual JSON compliant expression spec would be somewhat interesting, to capitalize on existing parsers and tooling. It would be even more interesting if it had a 1-1 mapping to scheme or some other Lisp. This accomplishes none of that.

The value of mobile code isn't exactly a new thing. I didn't even think it was a new thing for the JavaScript world.