3 ms·

Your example uses s-expressions, not canonical s-expressions. Canonical s expressions[1] is basically a binary format. Each atom/string is prefixed by a decimal

by thayne 1y ago

Your example uses s-expressions, not canonical s-expressions. Canonical s expressions[1] is basically a binary format. Each atom/string is prefixed by a decimal length of the string and a colon. It's advantage over regular s expressions is that there is no need to escape or quote strings with whitespace, and there is only a single possible representation for a given data structure. The disadvantage is it is much harder to write and read by humans. As for s-expressions vs json, there are pros and cons to each. S-expressions don't have any way to encode type information in the data itself, you need a schema to know if a certain value should be treated as a number or a string. And it's subjective which is more readable. [1]: https://en.m.wikipedia.org/wiki/Canonical_S-expressions https://en.m.wikipedia.org/wiki/Canonical_S-expressions

dietr1ch 1y ago
The length thing sounds like an editor problem, but we have wasted too much time in coming up with syntax that pleases personal preferences without admitting we would be better off moving away from text. 927 can be avoided, but it's way harder than it seems, which is why we have the proliferation of standards that fail to become universal.
eadmund 1y ago
> Your example uses s-expressions, not canonical s-expressions. I’ve always used ‘canonical S-expressions’ to refer to Rivest’s S-expressions proposal: https://www.ietf.org/archive/id/draft-rivest-sexp-13.html https://www.ietf.org/archive/id/draft-rivest-sexp-13.html, a proposal which has canonical, basic transport & advanced transport representations which are all equivalent to one another (i.e., every advanced transport representation has a single canonical representation). I don’t know where I first saw it, but perhaps it was intended to distinguish from other S-expressions such as Lisp’s or Scheme’s? Maybe I should refer to them as ‘Rivest S-expressions’ or ‘SPKI S-expressions’ instead. > S-expressions don't have any way to encode type information in the data itself, you need a schema to know if a certain value should be treated as a number or a string. Neither does JSON, as this whole thread indicates. This applies to other data types, too: while a Rivest expression could be (date [iso8601]2025-05-24T12:37:21Z) JSON is stuck with: { "date": "2025-05-24T12:37:21Z" } > And it's subjective which is more readable. I really disagree. The whole reason YAML exists is to make JSON more readable. Within limits, the more data one can have in a screenful of text, the better. JSON is so terribly verbose if pretty-printed that it takes up screens and screens of text to represent a small amount of data — and when not pretty-printed, it is close to trying to read a memory trace. Edit: updated link to the January 2025 proposal.
- antonvs 1y ago
  That Rivest draft defines canonical S-expressions to be the format in which every token is preceded by its length, so it's confusing to use "canonical" to describe the whole proposal, or use it as a synonym for the "advanced" S-expressions that the draft describes. But that perhaps hints at some reasons that formats like JSON tend to win popularity contests over formats like Rivest's. JSON is a single format for authoring and reading, which doesn't address transport at all. The name is short, pronounceable (vs. "spikky" perhaps?), and clearly refers to one thing - there's no ambiguity about whether you might be talking about a transport encoding instead, I'm not saying these are good reasons to adopt JSON over SPKI, just that there's a level of ambition in Rivest's proposal which is a poor match for how adoption tends to work in the real world. There are several mechanism for JSON transport encoding - including plain old gzip, but also more specific formats like MessagePack. There isn't one single standard for it, but as it turns out that really isn't that important. Arguably there's a kind of violation of separation of concerns happening in a proposal that tries to define all these things at once: "a canonical form ... two transport representations, and ... an advanced format".
  - kevin_thibedeau 1y ago
    > clearly refers to one thing Great, this looks like JSON. Is it JSON5? Does it expect bigint support? Can I use escape chars?
    - antonvs 1y ago
      You're providing an example of my point. People don't, in general, care about any of that, so "solving" those "problems" isn't likely to help adoption. To your specific points: 1. JSON5 didn't exist when JSON adoption occurred, and in any case they're pretty easy to tell apart, because JSON requires keys to be quoted. This is a non-problem. Why do you think it might matter? Not to mention that the existence of some other format that resembles JSON is hardly a reflection on JSON itself, except perhaps as a compliment to its perceived usefulness. 2. Bigint support is not a requirement that most people have. It makes no difference to adoption. 3. Escape character handling is pretty well defined in ECMA 404. Your point is so obscure I don't even know specifically what you might be referring to.

by thayne 1y ago

dietr1ch 1y ago

The length thing sounds like an editor problem, but we have wasted too much time in coming up with syntax that pleases personal preferences without admitting we would be better off moving away from text. 927 can be avoided, but it's way harder than it seems, which is why we have the proliferation of standards that fail to become universal.

eadmund 1y ago

> Your example uses s-expressions, not canonical s-expressions. I’ve always used ‘canonical S-expressions’ to refer to Rivest’s S-expressions proposal: https://www.ietf.org/archive/id/draft-rivest-sexp-13.html https://www.ietf.org/archive/id/draft-rivest-sexp-13.html, a proposal which has canonical, basic transport & advanced transport representations which are all equivalent to one another (i.e., every advanced transport representation has a single canonical representation). I don’t know where I first saw it, but perhaps it was intended to distinguish from other S-expressions such as Lisp’s or Scheme’s? Maybe I should refer to them as ‘Rivest S-expressions’ or ‘SPKI S-expressions’ instead. > S-expressions don't have any way to encode type information in the data itself, you need a schema to know if a certain value should be treated as a number or a string. Neither does JSON, as this whole thread indicates. This applies to other data types, too: while a Rivest expression could be (date [iso8601]2025-05-24T12:37:21Z) JSON is stuck with: { "date": "2025-05-24T12:37:21Z" } > And it's subjective which is more readable. I really disagree. The whole reason YAML exists is to make JSON more readable. Within limits, the more data one can have in a screenful of text, the better. JSON is so terribly verbose if pretty-printed that it takes up screens and screens of text to represent a small amount of data — and when not pretty-printed, it is close to trying to read a memory trace. Edit: updated link to the January 2025 proposal.

antonvs 1y ago
That Rivest draft defines canonical S-expressions to be the format in which every token is preceded by its length, so it's confusing to use "canonical" to describe the whole proposal, or use it as a synonym for the "advanced" S-expressions that the draft describes. But that perhaps hints at some reasons that formats like JSON tend to win popularity contests over formats like Rivest's. JSON is a single format for authoring and reading, which doesn't address transport at all. The name is short, pronounceable (vs. "spikky" perhaps?), and clearly refers to one thing - there's no ambiguity about whether you might be talking about a transport encoding instead, I'm not saying these are good reasons to adopt JSON over SPKI, just that there's a level of ambition in Rivest's proposal which is a poor match for how adoption tends to work in the real world. There are several mechanism for JSON transport encoding - including plain old gzip, but also more specific formats like MessagePack. There isn't one single standard for it, but as it turns out that really isn't that important. Arguably there's a kind of violation of separation of concerns happening in a proposal that tries to define all these things at once: "a canonical form ... two transport representations, and ... an advanced format".
- kevin_thibedeau 1y ago
  > clearly refers to one thing Great, this looks like JSON. Is it JSON5? Does it expect bigint support? Can I use escape chars?
  - antonvs 1y ago
    You're providing an example of my point. People don't, in general, care about any of that, so "solving" those "problems" isn't likely to help adoption. To your specific points: 1. JSON5 didn't exist when JSON adoption occurred, and in any case they're pretty easy to tell apart, because JSON requires keys to be quoted. This is a non-problem. Why do you think it might matter? Not to mention that the existence of some other format that resembles JSON is hardly a reflection on JSON itself, except perhaps as a compliment to its perceived usefulness. 2. Bigint support is not a requirement that most people have. It makes no difference to adoption. 3. Escape character handling is pretty well defined in ECMA 404. Your point is so obscure I don't even know specifically what you might be referring to.