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

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

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.

Boolean algebra with true and false was well established decades before computers were invented

Boolean algebra deals with logical propositions, not with configuration. The true/false terminology makes sense there.

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.

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.

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.

“yes” and “no” are “unfamiliar terms”? What the fuck? Everyone who knows even the basics of English knows what these words mean.

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.

Don’t give them any ideas! They already tried to make inroads with ruby’s “unless”.

Huh, I never considered this. we take true and false for granted everywhere but they aren't the most meaningful.

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.

Why do you need an alternative spelling of false?

`logging: no` clearly says “I do not want logging”. `logging: false` is less explicit – what exactly is false?

Then it should be on/off, not yes/no.

on/off also doesn’t make sense in many contexts, for example `isRegistered: on`.

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"

Logging: no could also be log in norwegian. Or log only for the norwegian region. That's the thing with too many keywords and optional quoting, you can't know.

And for this reason, "logging: false" would be clearer than "logging: no" to represent "I do not want logging".

`false` could be a code for something else just as well as `no`. For example, it could mean that I only want to see logs of false information appearing in the system. The only proper solution is to require quotes around strings.

Options are either

1. Specify in the key

  loggingEnabled: false

2. Specify in the value:

  logging: disabled

Logging: ignore/print/file

Don’t use bool at all.

This, along with number formats, could be a good argument for strings being the only primitive type in config languages.

I recently learned about NestedText: https://nestedtext.org/

While it has the YAML-like significant whitespace, it looks nice because it doesn't try to be clever.

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.

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.

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