String variants and language friendliness?

[Alch-Emi]

Hiya! I've been following the development on v2, and I like a lot of the new features, and I think they'll make it a lot easier and intuitive to write KDL. One thing I'm a little bit worried about though is the number of new string types.

I really do like the new dedenting in multiline strings, but as of writing, there will be a total of five types of strings in KDL, each with different opening/closing delimiters, different rules for which characters/character sequences are allowed, and whether escaping is permitted, forbidden, or ignored.

My fear is that this will conflict with KDL's goal of making KDL easy to read, write, and parse, especially for people unfamiliar with the language. While it's definitely convenient for someone familiar with the language to have a way of quickly writing a multi-line dedenting string which can contain three sequential unescaped quotation marks and in which single backslashes are preserved literally, someone new to the language probably wouldn't be able to figure out that they can use #""" to enable this behavior until they read the detailed documentation, or find a table on stack overflow.

On the parsing side of things, implementation is also a complicated slightly by having to parse five different variants of strings, each with slightly different rules, although this isn't as big of an issue imho.

All that said, I might be blowing this out of proportion, but I wanted to make a discussion to see what other people think. Any ideas on how (or if) strings could be made more intuitive and easy to pick up?

[zkat]

I get where you’re coming from, but I do see this as essential complexity in service of usability. For something that humans are expected to be able to easily author, sometimes you need to take into consideration the different scenarios in which they would want different representations of a data type.

Consider, for example, numbers: KDL’s data model essentially has a single numerical type, which is just “number”, but it… also has 5 different formats for representing them, and additionally has three symbols that are also meant to represent numbers. So 6-8 different number syntaxes, depending on how you want to count it.

And yet, all of those are useful and valuable to have for their respective use cases (consider, for example, having to represent a Unix acl value in something other than octal form, 0o644. And this is very likely something someone will want when editing a config file!)

The other practicality is one of safe migration. Until the dedent feature (which I do think is important!) was introduced, there were only 3 string syntaxes. With the dedenting added, it was still arguably 3, but with a special case around making regular strings spread across multiple lines.

Three triple quotes were introduced honestly out of necessity: outside of multi line strings, any valid v1 document that was also a valid v2 document was guaranteed to represent the same data. With multiline strings, an ambiguity was introduced.

So, the triple quotes are there so that you can have a clear migration path for folks currently using v1, and so KDL parsers can literally just try to parse as v2, and if it fails, try to parse as v1, and have that be a safe operation.

Anyway, I see where you’re coming from, but when I plug in things like migration, the actual usability of dedenting (which is largely becoming an expectation in modern languages), the massively increased ergonomics of identifier strings for simple values, and the usefulness of raw strings for, say, representing Windows paths, the calculus tips in favor of accepting the extra complexity (which, honestly, I don’t think is a lot.)

This is a good conversation to have, though, and these are just my 2c. Relative simplicity continues to be a goal for KDL, but for something humans will manually author, ergonomics for common use cases matter a lot, too.

[Alch-Emi]

That makes sense, and I get why they're necessary. Having slept on it, I think the thing that's getting to me has a lot more to do with discoverability than the number of types, especially since you pointed out the number of number syntaxes.

Things like hexadecimal numbers and ignored underscores in numbers are standard enough that I often discover a language has them just by trying it and not getting a syntax error. I think multiline and especially raw (and raw multiline!) strings have a far less standard implementation, and so users are less likely to discover them by trial and error, and in cases where users do know they exist, I think they'll be less likely to intuit their specific properties.

That said, I'm not sure that I can offer anything specific to do about this, so I suppose it boils down to idle wishing. Thank you very much for your thoughtful reply! I'll definitely continue to think about it!

[zkat]

Fwiw, raw strings are taken straight from Rust (with v2 removing the r prefix), and other languages also have equivalents, like C#’s @ strings.

but I do agree that making things easy to learn is important! I think doc improvements would go a long way here, but also possibly having KDL linters that recommend e.g. using multiline strings of you have a bunch of escaped newlines, or using raw strings if you have a bunch of \\ and other escapes.

[tabatkins]

Agreed that raw and multiline strings, while less common than a hex numeric syntax, are still reasonably common among programming languages. Python also has both raw strings (via the r prefix) and multiline strings started with a triple quote, for example.