4 ms·

Just wanted to add that this use might not be common in JSON but is extremely common in S-Expressions, which predate XML by 40 years or so, and are probably a b

Just wanted to add that this use might not be common in JSON but is extremely common in S-Expressions, which predate XML by 40 years or so, and are probably a better XML replacement than JSON (if you only regard technical details and ignore popularity and library/language support)

skybrian 9y ago
When people say this I wonder how much lisp readers are really standardized. (Consider reader macros.) It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants.
- ajanuary 9y ago
  I guess that's the problem edn [0] was trying to solve, but it doesn't have wide enough adoption. [0] https://github.com/edn-format/edn https://github.com/edn-format/edn
- beagle3 9y ago
  Common Lisp is reasonably standardized -- that's the whole point of Common Lisp, though it is hardly dominant. Among general Lisps and Schemes, readers are not standardized enough to say "kill XML, we'll just have S-Expr" (though I'm not sure what percentage of XML parsers out there follow the XML spec to the letter either).
- shakna 9y ago
  > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants. Scheme has a decent, albeit small, standard [0]. SXML [1] is also standardized, as part of that process, which makes writing it nice and predictable. So, for the most part, SXML should work the same between implementations, but, if it doesn't, all you need to construct an SXML object is: quote or quasiquote and unquote. SXML feels far more like a template language than a serialization format. --- But the wider question: > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate For the most part, they should be. But! S-Expressions are a terribly inefficient structure in memory, or rather, can be. How you optimise that can have some impact on what the reader accepts or rejects, or how it compiles into memory. Singly and doubly linked lists, vectors, arrays. S-Expressions can be all under the hood, or a mix. Some parsers reject variadic s-expressions, others accept them happily, but others have a limited recursion depth, so technically valid s-expressions get rejected. However, for the most part they're equal. --- [0] http://www.schemers.org/Documents/Standards/ http://www.schemers.org/Documents/Standards/ [1] http://okmij.org/ftp/Scheme/SXML.html http://okmij.org/ftp/Scheme/SXML.html

skybrian 9y ago

When people say this I wonder how much lisp readers are really standardized. (Consider reader macros.) It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants.

ajanuary 9y ago
I guess that's the problem edn [0] was trying to solve, but it doesn't have wide enough adoption. [0] https://github.com/edn-format/edn https://github.com/edn-format/edn
beagle3 9y ago
Common Lisp is reasonably standardized -- that's the whole point of Common Lisp, though it is hardly dominant. Among general Lisps and Schemes, readers are not standardized enough to say "kill XML, we'll just have S-Expr" (though I'm not sure what percentage of XML parsers out there follow the XML spec to the letter either).
shakna 9y ago
> It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate, even if they're both lisp variants. Scheme has a decent, albeit small, standard [0]. SXML [1] is also standardized, as part of that process, which makes writing it nice and predictable. So, for the most part, SXML should work the same between implementations, but, if it doesn't, all you need to construct an SXML object is: quote or quasiquote and unquote. SXML feels far more like a template language than a serialization format. --- But the wider question: > It's not clear I could find an s-expression parser in two different arbitrary languages and be sure they interoperate For the most part, they should be. But! S-Expressions are a terribly inefficient structure in memory, or rather, can be. How you optimise that can have some impact on what the reader accepts or rejects, or how it compiles into memory. Singly and doubly linked lists, vectors, arrays. S-Expressions can be all under the hood, or a mix. Some parsers reject variadic s-expressions, others accept them happily, but others have a limited recursion depth, so technically valid s-expressions get rejected. However, for the most part they're equal. --- [0] http://www.schemers.org/Documents/Standards/ http://www.schemers.org/Documents/Standards/ [1] http://okmij.org/ftp/Scheme/SXML.html http://okmij.org/ftp/Scheme/SXML.html