3 ms·

One of us is extraordinarily confused and I hope it isn't me. > Indeed but that doesn’t mean that JSON isn’t a subset of YAML. That > means that the strict

One of us is extraordinarily confused and I hope it isn't me. > Indeed but that doesn’t mean that JSON isn’t a subset of YAML. That > means that the strictness of JSON removes ambiguity of what is a > string and what is not while the lazy strings in YAML allow for ambiguity I ... don't think that's true. This isn't an issue of "strictness", and the document is unambiguous in both JSON and YAML. There's no question about correctness -- both parses appear to be correct for their respective languages. It's just that JSON and YAML disagree about whether the token `1e2` is an integer or a string. If LANG-X says that `1e2` is an integer and LANG-Y says it's a string, then axiomatically LANG-X cannot be considered a subset of LANG-Y. > It’s also worth noting that JSON doesn’t actually have a standard for > representing complex numbers. I don't see how that matters? `1e2` isn't a complex number, it's an integer. > In theory JSON should support scientific notation but [...] There's no "in theory" and no "but" here. Exponents are a part of the JSON spec, have been since the beginning, and are thoroughly documented in each iteration of the JSON RFC. A parser that can't parse {"a": 1e2} is not a JSON parser.

hnlmorg 4y ago
> I ... don't think that's true. This isn't an issue of "strictness", and the document is unambiguous in both JSON and YAML. There's no question about correctness -- both parses appear to be correct for their respective languages. It's just that JSON and YAML disagree about whether the token `1e2` is an integer or a string. My point was that because YAML supports unquoted strings, it means there is ambiguity (ie a lack of strictness) in the values you pass in a YAML document. This is exactly is issue demonstrated with the Norway Problem you referenced. If all strings were quoted when the Norway Problem wouldn't exist. But because YAML allows people to be lazy with quoting it introduces all kinds of edge case bugs that a stricter syntax would eradicate. > If LANG-X says that `1e2` is an integer and LANG-Y says it's a string, then axiomatically LANG-X cannot be considered a subset of LANG-Y. You're looking at it far to black and white. YAML does successfully parse JSON in almost all cases. YAML does also support scientific notation for numbers too. The problem here more of a bug than an intended break in compatibility. A bug that originates from its support of unquoted strings. The problem is YAML is a very complicated specification so bugs were inevitable. Thus I don't think it's unreasonable to still claim that YAML is a superset of JSON even in the presence of this bug. Plus this bug was fixed in YAML 1.2. > I don't see how that matters? `1e2` isn't a complex number, it's an integer. Sorry for the lack of clarity here. I meant "complex" as in "complicated" rather than the mathematical term "complex". However it's worth noting that you'll more often find scientific numbers used to represent floating point values rather than integers. Even in the case of very large integers, they'll end up being stored as a float in memory and output as an exponent. > There's no "in theory" and no "but" here. Exponents are a part of the JSON spec, have been since the beginning, and are thoroughly documented in each iteration of the JSON RFC. A parser that can't parse {"a": 1e2} is not a JSON parser. Yes, that's the "theory". But in practice (and as I'd already said) it's not always implemented correctly because: 1. JSON was based around JavaScript types and thus other languages haven't always implemented things exactly in the same way 2. JSON cannot be versioned so none of the other specifications mean jack shit since you cannot determine which standard a document was marshalled against (apparently this was an intentional decision). 3. There are plenty of other JSON parsers that intentionally parse JSON wrong because they attempt to fix (in their authors mind) some shortcomings of JSON. 4. JSON cannot be versioned so again here, you have no idea if one JSON parser is compliant and another is silently corrupting your data. YAML might have made a number of design errors but JSON gets a lot wrong too.

hnlmorg 4y ago

> I ... don't think that's true. This isn't an issue of "strictness", and the document is unambiguous in both JSON and YAML. There's no question about correctness -- both parses appear to be correct for their respective languages. It's just that JSON and YAML disagree about whether the token `1e2` is an integer or a string. My point was that because YAML supports unquoted strings, it means there is ambiguity (ie a lack of strictness) in the values you pass in a YAML document. This is exactly is issue demonstrated with the Norway Problem you referenced. If all strings were quoted when the Norway Problem wouldn't exist. But because YAML allows people to be lazy with quoting it introduces all kinds of edge case bugs that a stricter syntax would eradicate. > If LANG-X says that `1e2` is an integer and LANG-Y says it's a string, then axiomatically LANG-X cannot be considered a subset of LANG-Y. You're looking at it far to black and white. YAML does successfully parse JSON in almost all cases. YAML does also support scientific notation for numbers too. The problem here more of a bug than an intended break in compatibility. A bug that originates from its support of unquoted strings. The problem is YAML is a very complicated specification so bugs were inevitable. Thus I don't think it's unreasonable to still claim that YAML is a superset of JSON even in the presence of this bug. Plus this bug was fixed in YAML 1.2. > I don't see how that matters? `1e2` isn't a complex number, it's an integer. Sorry for the lack of clarity here. I meant "complex" as in "complicated" rather than the mathematical term "complex". However it's worth noting that you'll more often find scientific numbers used to represent floating point values rather than integers. Even in the case of very large integers, they'll end up being stored as a float in memory and output as an exponent. > There's no "in theory" and no "but" here. Exponents are a part of the JSON spec, have been since the beginning, and are thoroughly documented in each iteration of the JSON RFC. A parser that can't parse {"a": 1e2} is not a JSON parser. Yes, that's the "theory". But in practice (and as I'd already said) it's not always implemented correctly because: 1. JSON was based around JavaScript types and thus other languages haven't always implemented things exactly in the same way 2. JSON cannot be versioned so none of the other specifications mean jack shit since you cannot determine which standard a document was marshalled against (apparently this was an intentional decision). 3. There are plenty of other JSON parsers that intentionally parse JSON wrong because they attempt to fix (in their authors mind) some shortcomings of JSON. 4. JSON cannot be versioned so again here, you have no idea if one JSON parser is compliant and another is silently corrupting your data. YAML might have made a number of design errors but JSON gets a lot wrong too.