Proposal: support identifiers anywhere strings are accepted

[zkat]

I was looking at kdl-org/kdl-rs#58 and it made me think that maybe I should get over my stubbornness/aversion about allowing plain identifiers anywhere strings are allowed, just as we allow strings anywhere identifiers are allowed.

The reasoning being that, not just with the above example, but several other early KDL users have used it for simple DSLs for various purposes, and one of the things that always stood out about those DSLs was that a lot of things had to be strings that would look way better (and be easier to read), if they were simply identifiers.

This kind of thing isn't entirely without precedent. Many, if not most, configuration languages support unquoted string values, including YAML itself. But there's also a part of me that's a bit resistant because of potential confusion it might cause when someone's trying to figure out if they're able to use a plain identifier. But that's not a good argument against it because they already have to do that for other identifiers, like node names.

What do y'all think? This would be something we could get into the KDL 2.0 spec, and I think has some good potential.

[zkat]

Some feedback from Twitter:

(https://twitter.com/borland/status/1579194258007162880)

(https://twitter.com/jordansissel/status/1579193658351681536)

[Gankra]

I am mixed on this:

• It would make my Exact use case nicer (but I am doing something Cursed)

• I don't like inconsistencies ("always quoted" is consistent)

  • Although nodes already cheat (though they are indeed Special)
  • And raw strings already exist for "exceptional strings"

• Having less things syntactically valid is Good for producing good diagnostics / recovery

  • kdl-rs doesn't support recovery+multiple errors but it be nice if it did!
  • the case of x { y z } vs x { y; z; } is a very easy mistake to make, and the fact that the former is invalid is useful!

[tabatkins]

I do think this would make a lot of use-cases look a lot cleaner - a config I'm developing would certainly benefit somewhat from it. On the other hand, it makes KDL slightly more ambiguous.

Limiting it to just idents, rather than the wide-open "anything that's not already another syntax" that YAML does, does significantly limit the possible damage - the only ambiguities are true/false/null and I suppose adjacent child nodes like Gankra pointed out. (Tho that latter case is ambiguous in the same way today if you use string nodenames, tho admittedly those are intentionally extremely rare.)

As a big fan of unquoted attribute values in HTML, I think my ultimate vote is +1 on this.

[tabatkins]

This would also be the Big Difference that makes KDL 2.0 attractive to switch to, which is a potentially useful thing too.

[zkat]

I brought this up elsewhere, but what do you think of the now-possible scenario where someone writes:

foo bar=fasle

And let's say kdljs consumes it. In application code, there's a check like if (foonode.bar) { destroyTheWorld(); }. This seems like a potentially significant footgun that was just not present before?

[tabatkins]

I think that typos are problematic in all cases, regardless of quoting. "Bool becomes a string" doesn't seem significantly different from "string becomes a different, unexpected string". We can't protect people from typos in the general case, and having this one example produce a syntax error while extremely similar examples don't isn't particularly compelling to me. In particular, the original document could have been foo bar="fasle" with the code checking if (foonode.bar != "false") { destroyTheWorld(); }, and it would fail in the exact same way right now.

The confusing case we want to worry about, imo, is just the "person types exactly what they intend, but the language parses it in an unexpected way", aka the YAML issues with NO in a list of country abbreviations, or 3.11b and 3.12 in the same list.

This proposal only very narrowly touches on this, with someone potentially intending to provide the literal string "false" (or true/null) alongside a bunch of other single-word strings, and removing quotes from all of them and accidentally changing the meaning. But since there are precisely three such cases (unlike YAML where there's large classes of such things) I think it's an acceptable risk.

[bitzl]

I also think it makes configurations much cleaner. While I see strong consistency as very desireable (every string has quotes), for me the improved readbility would be more important.

[bitzl]

Just in case it might be helpful to have another use case: I'm currently thinking about a human friendly configuration language for a tool that takes information form serial port (e.g. an Arduino) and then sends it to one or many targets (e.g. OSC to make music):

routing {
    serial port "COM5" 
    send to OSC {
        host "localhost:8000"
        map values to {
            route "/instrument/1"
            route "/instrument/2"
            discard
            route "/instrument/3"
        }
    }
    send to stdout pretty=true
}

routing {
    serial port "/dev/ttyS0"
    send to stdout pretty=true
}

Quotes are needed wherever a value starts with /. In this case that's acutally improving readability, since I'd use quotes for all specific configuration parameters. To make implementiation easier, things like send to and serial port could also have dashes (send-to, serial-port), but that feels like stopping a few inches before the finishing line 😅

[larsgw]

I think this does make it more difficult for certain parsers: considering foo bar=false, when bar is processed it is not yet known whether it is a value or a property. IIRC this was part of the reason why true/false/null were disallowed, and the motivation behind #200.

I agree that it can make certain DSLs look more clean and consistent. I also agree that it makes typos in keywords harder to detect, and would like to add that foo bar=Project one might become intuitive to read/write but is incorrect as well.

[Gankra]

Oh right I forgot to mention that it only kind of makes my DSL easier.

I'm representing type declarations with rust-like syntax:

struct "Point" {
  x "u32"
  y "u32"
}

which would indeed be nicer as:

struct Point {
  x u32
  y u32
}

but I need full stringy fallback for delimiting nested/generic types:

struct "Matrix<T>" {
  vals "[[Option<T>; 10]; 10]"
}

So having bare ident strings would make like, 95% of my cases nicer at the cost of making the remaining 5% even more weird/confusing.

[djmattyg007]

Ambiguity is one of my chief problems with YAML. I was very happy when I came across KDL because it seemed to actively eschew these problems in favour of always being accurate.

I also have concerns over the parsing like someone else raised. It would make it unnecessarily complicated.

[zkat]

considering this "ambiguity" is only for identifier vs strings, which is something that already applies to all identifiers (since they can all be written as strings), and tbh, as an implementor, this would not be hard to implement for me. Does that sway you at all?

[larsgw]

Oh right, I didn't think of that.

[Gankra]

for me the concern is less implementation and more "common/reasonable mistakes forming valid documents with wildly different meanings and causing confusion/messes".

[tabatkins]

Another argument in favor of this is that it lets you treat arguments as being value-less properties. That is, if you have node foo="bar", you can also have node foo to just mean foo with a default value.

(And just double-checking - yup, you can't today have a property name using the identifer true/etc; you have to quote the property name there.)

[MultisampledNight]

Already gave my +1 per reaction but I still think that this might be relevant: In my case I intend to have arguments to be able to link to the other nodes through their identifiers, and also add some operations to them (in the context of colors). For example, take this:

cool-cyan "oklch(70% 0.098 181.69)"
accent cool-cyan
secondary accent - "25% lightness"

This ^ would be so much cleaner to me than

cool-cyan "oklch(70% 0.098 181.69)"
accent "cool-cyan"
secondary "accent" "-" "25% lightness"

But to be honest, this is also a pretty obscure usecase, and probably kdl was not intended to be the basis for a whole weird DSL like this. Still, would be nice to have since almost every other aspect of kdl fits my case perfectly right now.

[MultisampledNight]

Wondering if I should just fork KDL to cursDL and reduce it down to my exact needs, actually, since I need some parsing ontop of an entry's arguments and properties anyway, which would also involve "types" being treated very differently. Hm.

[gamma-delta]

FWIW, I'm using KDL for a blueprinting system for games right now. Here's an example: https://github.com/gamma-delta/palkia/blob/main/tests/fabricator/simple.rs

Having quoteless strings in these cases would be really handy, especially when the thing I'm deserializing is logically an identifier and not a string. (This is also why I'd like forward-slash to be allowed in identifiers, to logically group similar blueprints together. Currently I'm settling for things like window?fore and window?aft, and I think it would look much better as window/fore and window/aft.

In a perfect magic world I'd like these quoteless strings to be a new "identifier" type, but that's probably just my Lisp brainrot talking.

[larsgw]

What about using annotations like (window)fore? I don't know if that would make sense in your system though.

[marrus-sh]

i prefer KDL’s existing behaviour because i think having the value syntax be a superset of the identifier syntax makes things more confusing for downstream specifications which might want behaviours for one but not the other. right now KDL has:

• "identifiers" [node names, type annotations, property keys] (syntax: identifier or string)

• "values" [arguments, property values] (syntax: string, number, boolean, null)

there's some confusion between identifier-the-syntax and identifier-the-concept but it's largely able to be handwaved because the former only appears in the latter case

however

i think if a downstream specification wanted to specify special rules for identifiers (the concept), a lot of people would expect those behaviours anywhere identifiers (the syntax) are allowed. because the value syntax becomes a superset of the identifier syntax, people will expect value behaviours to be a superset of identifier behaviours. but there's lots of reasons (i think) why you would want strings in values not to behave like identifiers and just to behave like strings.

this opens the door to people asking: why not just let node names be any kind of value? why do property keys always have to be strings? right now it's clear that identifiers and values are different concepts that just happen to share a syntax in the complex case, but this becomes a lot less clear when every identifier is also a value.

anyway. this is maybe not a problem for KDL itself, but i think worth considering

[zkat]

I'm of the mind right now that this is valuable enough for a human-centered configuration language that we should go ahead and do it, regardless of the identified footguns. I've made an issue for KDL 2.0 here, which folks are welcome to upvote/downvote as needed.