Hacker News Reader

Comment by airstrike | Hacker News Reader

> 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.

View on HN

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.

So basically JSON5, while not being a standard.

> • 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? */

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

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.

Reply on news.ycombinator.com