5 ms·

J-expressions (2012)

36 points by galfarragem 12y ago

netcraft 12y ago
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-using-j-expressions/ 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.
- galfarragem 12y ago
  Yep, that's the proper link. Disclaimer: I made the post in HN but (unfortunately) I'm not the blog author.
nine_k 12y ago
See https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule That 'half of Common Lisp' thing keeps popping everywhere, unless explicitly planned.
- duaneb 12y ago
  Ironically, I think common lisp is itself 'an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp'.
  - AnimalMuppet 12y ago
    That is in fact Morris's Corollary to Greenspun's Tenth Rule.
cbsmith 12y ago
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.
angersock 12y ago
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.
- thyrsus 12y ago
  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"] ] }
  - emeraldd 12y ago
    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.
    - dugmartin 12y ago
      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 https://www.hackerschool.com/blog/21-little-lisp-interpreter. Might be an interesting way to expose an api.
- jerf 12y ago
  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.
davexunit 12y ago
Just use s-expressions, already.
- oconnore 12y ago
  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.

36 points by galfarragem 12y ago

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-using-j-expressions/ 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.

galfarragem 12y ago
Yep, that's the proper link. Disclaimer: I made the post in HN but (unfortunately) I'm not the blog author.

nine_k 12y ago

See https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule That 'half of Common Lisp' thing keeps popping everywhere, unless explicitly planned.

duaneb 12y ago
Ironically, I think common lisp is itself 'an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp'.
- AnimalMuppet 12y ago
  That is in fact Morris's Corollary to Greenspun's Tenth Rule.

cbsmith 12y ago

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.

angersock 12y ago

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.

thyrsus 12y ago
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"] ] }
- emeraldd 12y ago
  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.
  - dugmartin 12y ago
    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 https://www.hackerschool.com/blog/21-little-lisp-interpreter. Might be an interesting way to expose an api.
jerf 12y ago
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.

davexunit 12y ago

Just use s-expressions, already.

oconnore 12y ago
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.