4 ms·

This article claims that 1e2 is interpreted as a string, while this other article on the front page[0] claims that 556474e378 is interpreted as a number. What's

This article claims that 1e2 is interpreted as a string, while this other article on the front page[0] claims that 556474e378 is interpreted as a number. What's correct? The YAML "Scalars" section[1] says: > A few examples also use the int, float and null types from the JSON schema. And includes these examples: canonical: 1.23015e+3 exponential: 12.3015e+02 So, is the "+" required here or not? Is a YAML parser buggy if it doesn't parse all JSON numbers as numbers? Edit: Ah, further on, it says: Canonical Form Either 0, .inf, -.inf, .nan or scientific notation matching the regular expression -? [1-9] ( \. [0-9]* [1-9] )? ( e [-+] [1-9] [0-9]* )? The example 1e2 clearly matches this regex, so his YAML parser is broken. Edit edit: In YAML 1.1, there were separate definitions of float[2] and int[3] types, where only floats support "scientific" notation, and must have a ".", unlike JSON. So this article is talking about YAML 1.1, while the other article is talking about YAML 1.2. [0] https://news.ycombinator.com/item?id=41498264 https://news.ycombinator.com/item?id=41498264 [1] https://yaml.org/spec/1.2.2/#23-scalars https://yaml.org/spec/1.2.2/#23-scalars [2] https://yaml.org/type/float.html https://yaml.org/type/float.html [3] https://yaml.org/type/int.html https://yaml.org/type/int.html

endycm 2y ago
No, the YAML parser is a valid YAML 1.1 parser, where this behaviour is totally correct and in spec.
jmillikin 2y ago
What's "correct" depends on whether your YAML parser defaults to YAML 1.1 or 1.2. Most YAML parsers default to 1.1 for compatibility reasons, because if they default to 1.2 then existing YAML documents expecting 1.1 behavior will be parsed incorrectly. YAML is a difficult language to parse if you care about getting the correct data.
- soco 2y ago
  Which only goes to prove that every replacement of XML eventually ran into the exactly same complexity issues they thought to solve in the first place. Another example of why "just use..." is a losing approach.
n2d4 2y ago
> The example 1e2 clearly matches this regex, so his YAML parser is broken. 1e2 does not match this regex. 1e+2 or 1e-2 would, though.
- lifthrasiir 2y ago
  The "canonical" form indeed requires an exponent sign, but the tag resolution process in YAML 1.2 (section 10.2.2) does allow its omission. That said however, the equivalent specification in YAML 1.1 [1] does require an exponent sign at any case! It should be no surprise that YAML 1.1 isn't a superset of any version of JSON, but I don't know whether this is intentional or simply an oversight. [1] https://yaml.org/type/float.html https://yaml.org/type/float.html
  - n2d4 2y ago
    YAML 1.2.2 still isn't a superset of JSON, because it requires all keys to be unique: > The content of a mapping node is an unordered set of key/value node pairs, with the restriction that each of the keys is unique
    - lifthrasiir 2y ago
      While JSON doesn't prevent duplicate keys per se, it doesn't fully specify its semantics anyway and only states that duplicate keys are less "interoperable". And there is an explicit profile of JSON with this requirement (I-JSON [1]), so YAML 1.2.2 can be said to be a superset of some version of JSON. [1] https://datatracker.ietf.org/doc/html/rfc7493 https://datatracker.ietf.org/doc/html/rfc7493
      - n2d4 2y ago
        "X is a superset of some subset of Y" is a weak statement. This is not about semantics, it's about grammar. While it's fair to say that JSON "usually" is valid YAML, it's still good to be strict about it, because the existence of a single counterexample can be used maliciously.
xelxebar 2y ago
> So this article is talking about YAML 1.1, while the other article is talking about YAML 1.2. Precisely. The article is really noticing quirks and limitations libyaml, the library doing the heavy lifting behind PyYAML, not YAML-the-spec proper. Granted, in practice, library limitations are probably what you want to know about. AFAIK, libfyaml[0] (not libyaml) is the most spec-compliant library around. It's a shame more downstream languages aren't using it. [0]:https://github.com/pantoniou/libfyaml https://github.com/pantoniou/libfyaml

endycm 2y ago

No, the YAML parser is a valid YAML 1.1 parser, where this behaviour is totally correct and in spec.

jmillikin 2y ago

What's "correct" depends on whether your YAML parser defaults to YAML 1.1 or 1.2. Most YAML parsers default to 1.1 for compatibility reasons, because if they default to 1.2 then existing YAML documents expecting 1.1 behavior will be parsed incorrectly. YAML is a difficult language to parse if you care about getting the correct data.

soco 2y ago
Which only goes to prove that every replacement of XML eventually ran into the exactly same complexity issues they thought to solve in the first place. Another example of why "just use..." is a losing approach.

n2d4 2y ago

> The example 1e2 clearly matches this regex, so his YAML parser is broken. 1e2 does not match this regex. 1e+2 or 1e-2 would, though.

lifthrasiir 2y ago
The "canonical" form indeed requires an exponent sign, but the tag resolution process in YAML 1.2 (section 10.2.2) does allow its omission. That said however, the equivalent specification in YAML 1.1 [1] does require an exponent sign at any case! It should be no surprise that YAML 1.1 isn't a superset of any version of JSON, but I don't know whether this is intentional or simply an oversight. [1] https://yaml.org/type/float.html https://yaml.org/type/float.html
- n2d4 2y ago
  YAML 1.2.2 still isn't a superset of JSON, because it requires all keys to be unique: > The content of a mapping node is an unordered set of key/value node pairs, with the restriction that each of the keys is unique
  - lifthrasiir 2y ago
    While JSON doesn't prevent duplicate keys per se, it doesn't fully specify its semantics anyway and only states that duplicate keys are less "interoperable". And there is an explicit profile of JSON with this requirement (I-JSON [1]), so YAML 1.2.2 can be said to be a superset of some version of JSON. [1] https://datatracker.ietf.org/doc/html/rfc7493 https://datatracker.ietf.org/doc/html/rfc7493
    - n2d4 2y ago
      "X is a superset of some subset of Y" is a weak statement. This is not about semantics, it's about grammar. While it's fair to say that JSON "usually" is valid YAML, it's still good to be strict about it, because the existence of a single counterexample can be used maliciously.

xelxebar 2y ago

> So this article is talking about YAML 1.1, while the other article is talking about YAML 1.2. Precisely. The article is really noticing quirks and limitations libyaml, the library doing the heavy lifting behind PyYAML, not YAML-the-spec proper. Granted, in practice, library limitations are probably what you want to know about. AFAIK, libfyaml[0] (not libyaml) is the most spec-compliant library around. It's a shame more downstream languages aren't using it. [0]:https://github.com/pantoniou/libfyaml https://github.com/pantoniou/libfyaml