4 ms·

> But why? It's literally in the README... • Less syntactic noise, more intuitive look. • Allow comments and trailing commas. • Write KEON almost

> But why? It's literally in the README... • Less syntactic noise, more intuitive look. • Allow comments and trailing commas. • Write KEON almost like you write Rust: - Humanized optional type annotation. - Distinguishable between tuples and lists (seqs). - Arbitrary type as dictionary (map) keys. ... • Shorthand for newtypes. • Support use Base64, Base32 and Base16 to represent bytes. • Provide paragraphs may be helpful when writing something by hand. JSON is pretty terrible. Its only real pro is the fact that it is widely used.

Rantenki 2y ago
As a comparison, here's the "Why RON" for the native RON/Rust format: Note the following advantages of RON over JSON: * trailing commas allowed * single- and multi-line comments * field names aren't quoted, so it's less verbose * optional struct names improve readability * enums are supported (and less verbose than their JSON representation) I feel like they are close enough that it would be better to just use RON, which has existing uptake/tooling.
- pjmlp 2y ago
  So basically JSON5, while not being a standard.
cryptonector 2y ago
> • Allow comments Ok, but whence the comments when serializing, and what does the codec do with comments when deserializing? Adding comments to JSON wouldn't be hard syntactically speaking, but semantically it's a real problem not just for JSON but for every encoding where the encoded data isn't the source of truth. Put another way, if I maintain XML, JSON, etc. by hand with $EDITOR, then embedded comments are sensible, but if XML, JSON, etc. are generated from an internal representation then now we have to wonder "what elements of the internal representation are the comments associated with, how do we ensure we represent that association when encoding, and how do we ensure that on decode we get the comments associated with the same elements. /* Is this comment associated with the following value? Surely not with the preceding one since there isn't one! */ { "foo" /* what about this one? */: /* or this one? */ "bar" /* or... */ } /* And what about this one? */
- airstrike 2y ago
  Just drop the comments. They are comments, which means they should be ignored when parsing. I just want to be able to parse files with comments instead of getting an error. Same for trailing commas
  - cryptonector 2y ago
    Sure, no problem. But then your users will ask you to preserve comments. How do I know? Because we've seen that request in jq multiple times.

Rantenki 2y ago

As a comparison, here's the "Why RON" for the native RON/Rust format: Note the following advantages of RON over JSON: * trailing commas allowed * single- and multi-line comments * field names aren't quoted, so it's less verbose * optional struct names improve readability * enums are supported (and less verbose than their JSON representation) I feel like they are close enough that it would be better to just use RON, which has existing uptake/tooling.

pjmlp 2y ago
So basically JSON5, while not being a standard.

cryptonector 2y ago

> • Allow comments Ok, but whence the comments when serializing, and what does the codec do with comments when deserializing? Adding comments to JSON wouldn't be hard syntactically speaking, but semantically it's a real problem not just for JSON but for every encoding where the encoded data isn't the source of truth. Put another way, if I maintain XML, JSON, etc. by hand with $EDITOR, then embedded comments are sensible, but if XML, JSON, etc. are generated from an internal representation then now we have to wonder "what elements of the internal representation are the comments associated with, how do we ensure we represent that association when encoding, and how do we ensure that on decode we get the comments associated with the same elements. /* Is this comment associated with the following value? Surely not with the preceding one since there isn't one! */ { "foo" /* what about this one? */: /* or this one? */ "bar" /* or... */ } /* And what about this one? */

airstrike 2y ago
Just drop the comments. They are comments, which means they should be ignored when parsing. I just want to be able to parse files with comments instead of getting an error. Same for trailing commas
- cryptonector 2y ago
  Sure, no problem. But then your users will ask you to preserve comments. How do I know? Because we've seen that request in jq multiple times.