3 ms·

I'm skimming through the human readable spec, and it seems decent, but I noticed the spec allows unquoted strings. What's the reasoning for this? In my experien

I'm skimming through the human readable spec, and it seems decent, but I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords. Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read.

kstenerud 6y ago
> I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords. Unquoted strings are much nicer for humans to work with. All special keywords and object encodings are prefixed with sigils (@, &, $, #, etc), so any bare text starting with a letter is either a string or an invalid document, and any bare text starting with a numeral is either a number or an invalid document. > Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read. I use a superset of those keywords to give more precision in meaning: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#terms https://github.com/kstenerud/concise-encoding/blob/master/ce...
- chousuke 6y ago
  If strings are always unambiquously detectable, why allow quoting them at all? Having two representations for the same data means you can't normalize a document unambiguously. I can understand having barewords seems cleaner for things like map keys, but I am not convinced that it's a worthwhile tradeoff. An important feature of RFC2119 keywords is that they're always capitalized (ie. the keyword is "MUST", not "Must", or "must"). This makes requirements and recommendations stand out amid explanatory text, improving legibility. For example, RFC2119 itself uses MUST and must with different meanings.
  - kstenerud 6y ago
    > If strings are always unambiquously detectable, why allow quoting them at all? Because strings can contain whitespace and other structural characters that would confuse a parser. > Having two representations for the same data means you can't normalize a document unambiguously. The document will always be normalized unambiguously in binary format. The text format is a bit more lenient because humans are involved. The idea is that the binary format is the source of truth, and is what is used in 90% of situations. The text format is only needed as a conduit for human input, or as a human readable representation of the binary data when you need to see what's going on. > An important feature of RFC2119 keywords is that they're always capitalized (ie. the keyword is "MUST", not "Must", or "must"). Hmm good point. I'll add that.
  - kstenerud 6y ago
    Update: I'm removing unquoted strings. Thanks for the critique!

kstenerud 6y ago

> I noticed the spec allows unquoted strings. What's the reasoning for this? In my experience unquoted strings cause nothing but trouble, and are confusing to humans who may interpret them as keywords. Unquoted strings are much nicer for humans to work with. All special keywords and object encodings are prefixed with sigils (@, &, $, #, etc), so any bare text starting with a letter is either a string or an invalid document, and any bare text starting with a numeral is either a number or an invalid document. > Any reason for not using RFC2119 keywords in the spec? Using them should make the spec easier to read. I use a superset of those keywords to give more precision in meaning: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#terms https://github.com/kstenerud/concise-encoding/blob/master/ce...

chousuke 6y ago
If strings are always unambiquously detectable, why allow quoting them at all? Having two representations for the same data means you can't normalize a document unambiguously. I can understand having barewords seems cleaner for things like map keys, but I am not convinced that it's a worthwhile tradeoff. An important feature of RFC2119 keywords is that they're always capitalized (ie. the keyword is "MUST", not "Must", or "must"). This makes requirements and recommendations stand out amid explanatory text, improving legibility. For example, RFC2119 itself uses MUST and must with different meanings.
- kstenerud 6y ago
  > If strings are always unambiquously detectable, why allow quoting them at all? Because strings can contain whitespace and other structural characters that would confuse a parser. > Having two representations for the same data means you can't normalize a document unambiguously. The document will always be normalized unambiguously in binary format. The text format is a bit more lenient because humans are involved. The idea is that the binary format is the source of truth, and is what is used in 90% of situations. The text format is only needed as a conduit for human input, or as a human readable representation of the binary data when you need to see what's going on. > An important feature of RFC2119 keywords is that they're always capitalized (ie. the keyword is "MUST", not "Must", or "must"). Hmm good point. I'll add that.
- kstenerud 6y ago
  Update: I'm removing unquoted strings. Thanks for the critique!