4 ms·

This has been fixed since 2009 with YAML 1.2. The problem is that everyone uses libyaml (_e.g._ PyYAML _etc._) which is stuck on 1.1 for reasons. The 1.2 spec

This has been fixed since 2009 with YAML 1.2. The problem is that everyone uses libyaml (_e.g._ PyYAML _etc._) which is stuck on 1.1 for reasons. The 1.2 spec just treats all scalar types as opaque strings, along with a configurable mechanism[0] for auto-converting non-quoted scalars if you so please. As such, I really don't quite grok why upstream libraries haven't moved to YAML 1.2. Would love to hear details from anyone with more info. [0]:https://yaml.org/spec/1.2.2/#chapter-10-recommended-schemas https://yaml.org/spec/1.2.2/#chapter-10-recommended-schemas

xigoi 2y ago
I’m sad that the “fix” was to disallow “no” as a more readable alternative to “false”, rather than to disallow unquoted strings.
- xelxebar 2y ago
  The fix is to make conversion user-controllable. If you want to disallow bare scalars except for booleans and numbers or whatever, it's just a little bit of configuration away.
- mckn1ght 2y ago
  It’s silly to have so many keyword synonyms as specified in that earlier regex. I’m also glad we can’t specify numeric literals as roman numerals. KISS
  - xigoi 2y ago
    Honestly I’d prefer if “yes” and “no” were the only ways to spell the boolean values. They make sense in pretty much all contexts where booleans are used, whereas “true” and “false” rarely make sense.
    - tacker2000 2y ago
      In boolean logic true/false is ubiquitious and well known. As you can see, if one tries to be cute with it, one will get all sorts of issues. So at this point it doesnt make sense to use anything else.
      - xigoi 2y ago
        The true/false terminology makes sense in boolean logic because you’re dealing with the truth of propositions. However, it does not make sense in the context of a configuration language, where there are no propositions that could be true or false.
        stevage 2y ago
        Huh, I never considered this. we take true and false for granted everywhere but they aren't the most meaningful.
        School-Cotton 2y ago
        It makes sense in the context of a configuration language because virtually 100% of programmers and other technical computer users understand “true” and “false” as the canonical Boolean values, and as far as I know that has always been the case. It never would have made sense to invent different unfamiliar terms like “yes” and “no” because of some niche philosophical distinction between “Boolean logic” and “configuration” that almost nobody in the real world cares about.
        xigoi 2y ago
        “yes” and “no” are “unfamiliar terms”? What the fuck? Everyone who knows even the basics of English knows what these words mean.
        School-Cotton 2y ago
        They are familiar as English words, yes, but unfamiliar as terms of art for Boolean values in computing. It’d be like replacing “if” statements with “whenever” statements.
    - dtech 2y ago
      Boolean algebra with true and false was well established decades before computers were invented
      - xigoi 2y ago
        Boolean algebra deals with logical propositions, not with configuration. The true/false terminology makes sense there.
      - deleted 2y ago
        [deleted]
- pydry 2y ago
  Yeah, you still get the same issue that 3 is an integer, 3.3 is a float and 3.3.3 is a string.
- heavenlyblue 2y ago
  Why do you need an alternative spelling of false?
  - xigoi 2y ago
    `logging: no` clearly says “I do not want logging”. `logging: false` is less explicit – what exactly is false?
    - jeltz 2y ago
      Then it should be on/off, not yes/no.
      - xigoi 2y ago
        on/off also doesn’t make sense in many contexts, for example `isRegistered: on`.
        qw 2y ago
        I often prefer enums over booleans for this. It seems more readable for most cases, and can be extended with new values. This: isRegistered: true could be replaced with accountStatus: "UNREGISTRED"
        deleted 2y ago
        [deleted]
    - qznc 2y ago
      Logging: ignore/print/file Don’t use bool at all.
      - xigoi 2y ago
        This, along with number formats, could be a good argument for strings being the only primitive type in config languages.
maxloh 2y ago
Why wasn't that a major version bump, like YAML 2.0? That sounds like a breaking change that rendered old YAML documents to be parsed differently.
transfire 2y ago
Absolutely correct! Please correct me if I am wrong, but as far as I know, no one has implemented YAML completely according to spec. The tag schema used is supposed to be modifiable folks! And why anyone would still be using 1.1 at this point is just forehead palming foolishness.
- xelxebar 2y ago
  AFAIK, libfyaml[0] (not to be confused with libyaml) passes the 1.2 test suite, and if I remember correctly, it's currently the only YAML loader with that claim at the moment. The yaml.orf website also lists a bunch of implementations, with about 1/3 supporting 1.2. I'm guessing that the users of those libraries just happily hum along and we never hear from them! The issue is that downstream consumers of popular languages with a vocal community here on HN tend to just pull in libyaml, PyYAML being the major offender in my mind. [0]:https://github.com/pantoniou/libfyaml https://github.com/pantoniou/libfyaml

xigoi 2y ago

I’m sad that the “fix” was to disallow “no” as a more readable alternative to “false”, rather than to disallow unquoted strings.

xelxebar 2y ago
The fix is to make conversion user-controllable. If you want to disallow bare scalars except for booleans and numbers or whatever, it's just a little bit of configuration away.
mckn1ght 2y ago
It’s silly to have so many keyword synonyms as specified in that earlier regex. I’m also glad we can’t specify numeric literals as roman numerals. KISS
- xigoi 2y ago
  Honestly I’d prefer if “yes” and “no” were the only ways to spell the boolean values. They make sense in pretty much all contexts where booleans are used, whereas “true” and “false” rarely make sense.
  - tacker2000 2y ago
    In boolean logic true/false is ubiquitious and well known. As you can see, if one tries to be cute with it, one will get all sorts of issues. So at this point it doesnt make sense to use anything else.
    - xigoi 2y ago
      The true/false terminology makes sense in boolean logic because you’re dealing with the truth of propositions. However, it does not make sense in the context of a configuration language, where there are no propositions that could be true or false.
      - stevage 2y ago
        Huh, I never considered this. we take true and false for granted everywhere but they aren't the most meaningful.
      - School-Cotton 2y ago
        It makes sense in the context of a configuration language because virtually 100% of programmers and other technical computer users understand “true” and “false” as the canonical Boolean values, and as far as I know that has always been the case. It never would have made sense to invent different unfamiliar terms like “yes” and “no” because of some niche philosophical distinction between “Boolean logic” and “configuration” that almost nobody in the real world cares about.
        xigoi 2y ago
        “yes” and “no” are “unfamiliar terms”? What the fuck? Everyone who knows even the basics of English knows what these words mean.
        School-Cotton 2y ago
        They are familiar as English words, yes, but unfamiliar as terms of art for Boolean values in computing. It’d be like replacing “if” statements with “whenever” statements.
  - dtech 2y ago
    Boolean algebra with true and false was well established decades before computers were invented
    - xigoi 2y ago
      Boolean algebra deals with logical propositions, not with configuration. The true/false terminology makes sense there.
    - deleted 2y ago
      [deleted]
pydry 2y ago
Yeah, you still get the same issue that 3 is an integer, 3.3 is a float and 3.3.3 is a string.
heavenlyblue 2y ago
Why do you need an alternative spelling of false?
- xigoi 2y ago
  `logging: no` clearly says “I do not want logging”. `logging: false` is less explicit – what exactly is false?
  - jeltz 2y ago
    Then it should be on/off, not yes/no.
    - xigoi 2y ago
      on/off also doesn’t make sense in many contexts, for example `isRegistered: on`.
      - qw 2y ago
        I often prefer enums over booleans for this. It seems more readable for most cases, and can be extended with new values. This: isRegistered: true could be replaced with accountStatus: "UNREGISTRED"
      - deleted 2y ago
        [deleted]
  - qznc 2y ago
    Logging: ignore/print/file Don’t use bool at all.
    - xigoi 2y ago
      This, along with number formats, could be a good argument for strings being the only primitive type in config languages.

maxloh 2y ago

Why wasn't that a major version bump, like YAML 2.0? That sounds like a breaking change that rendered old YAML documents to be parsed differently.

transfire 2y ago

Absolutely correct! Please correct me if I am wrong, but as far as I know, no one has implemented YAML completely according to spec. The tag schema used is supposed to be modifiable folks! And why anyone would still be using 1.1 at this point is just forehead palming foolishness.

xelxebar 2y ago
AFAIK, libfyaml[0] (not to be confused with libyaml) passes the 1.2 test suite, and if I remember correctly, it's currently the only YAML loader with that claim at the moment. The yaml.orf website also lists a bunch of implementations, with about 1/3 supporting 1.2. I'm guessing that the users of those libraries just happily hum along and we never hear from them! The issue is that downstream consumers of popular languages with a vocal community here on HN tend to just pull in libyaml, PyYAML being the major offender in my mind. [0]:https://github.com/pantoniou/libfyaml https://github.com/pantoniou/libfyaml