Why must strings be quoted?

[KallDrexx]

Is there a reason that single word strings must be quoted?

I was excited about KDL as a configuration format because it seemed like something that will make configurations easier for non-engineers than YAML or JSON. However, I am concerned about the requirement for strings to be quoted.

For example, in my application I had the following config I was trying to test with:

settings {
    feature_a on
    feature_b restricted_mode
}

This fails to parse in spec compliant parsers which made me really confused. It seems to have failed because on and restricted_mode both need to be quoted for it to work. However, how am I supposed to effectively communicate that to users?

Parsers still must do multiple passes over a single argument, so I am having a tough time seeing the benefit of this requirement. For example, each argument I would need to see if it starts with a quote, is it null, is it a number, if it's a number does it have a decimal place, etc... It seems to me that if it's an unquoted value that's not null, and not a number it should fall back to a string.

[larsgw]

I can't find the original discussion, but non-quoted strings are not supported on purpose to avoid syntax ambiguities, if I remember correctly.

[KallDrexx]

That's a shame. For context, I spent a good bit of time trying to figure out why my KDL didn't work and had to dig through the spec to finally figure it out. I obviously can't expect non-engineering users of my software to go through the KDL spec to write configs for my software, nor am I looking forward to answering user tickets that require me to dig through their KDL configs to let them know that "you are doing foo=bar when you need to do foo="bar" instead".

I could work around it if on and restricted_mode are instead parsed as property keys without a value (since they technically qualify as identifiers), but that doesn't seem to be the case in the spec either (though that wouldn't help the property value issue).

[tabatkins]

Unquoted strings are one of the errors YAML made that we'd like to avoid, the old "you wrote NO in your list of country abbreviations to mean Norway, but what you got was a false bool" problem.

KDL has less keywords (only true/false/null), but people run into issues with YAML parsing even for those shared keywords, where they unexpectedly get a keyword rather than the string they intended. See also things like 1.1 parsing as a number but 1.1.1 parsing as an unquoted string; type confusion, again, but also guess what happens when you write version 1.10!

All in all, the convenience of unquoted strings in simple keywordish cases like foo=bar seems to be outweighed by the problematic parsing ambiguities of cases like true or 1.1 in contexts where they're meant to be strings. At least, that's the conclusion that Kat reached when designing KDL, and I agree with it.

I obviously can't expect non-engineering users of my software to go through the KDL spec to write configs for my software,

Of course not, but there are tons of examples of strings as arguments and property values at https://kdl.dev; if you follow the structure of any of them you'll be fine. It's only if you come in with preconceptions from unrelated languages like YAML that you might have trouble.

[eugenesvk]

KDL has less keywords (only true/false/null), but people run into issues with YAML parsing even for those shared keywords, where they unexpectedly get a keyword rather than the string they intended. See also things like 1.1 parsing as a number but 1.1.1 parsing as an unquoted string; type confusion, again, but also guess what happens when you write version 1.10!

Isn't this neatly solved via using syntax highlighting? Then 1.1 will have different color vs 1.1.1, so the feedback is immediate, and then the color change again when you do 1.10?

[tabatkins]

The fact that people keep committing the error in YAML suggests that no, syntax highlighting is not a sufficient guard against misinterpretation. (The obvious reason why not is that not everyone uses syntax highlighting on every file, in every program.)