Hacker News Reader

Comment by xelxebar | Hacker News Reader

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

View on HN

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

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.

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.

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.

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

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”.

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.

Yeah, you still get the same issue that 3 is an integer, 3.3 is a float and 3.3.3 is a string.

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: 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.

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

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

Reply on news.ycombinator.com