KenKundert / nestedtext

Human readable and writable data interchange format
https://nestedtext.org
MIT License
362 stars 13 forks source link

Consider adding inline collection literals? #9

Closed matklad closed 3 years ago

matklad commented 3 years ago

Hi! This is more of an experience report, rather than an issue :) I've tried converting moderatly complex toml documents to nestedtext:

https://gist.github.com/matklad/8e7502a83e5492040c4436b716922bf5

Overall, I like low-ceremony and simplicity of nestedtext, and I especially enjoy the fact that there's only one scalar data type -- a string. For my tomls, this is especially nice, because having to quote semantic versions always irked me.

However, I find the converted documents harder to read, because they are long and narrow. The second one has roughtly twice as many lines. I do think this significantly affects readability, as there's simply to little info on a line to get many important bits a glance (naturally, the flip side of this is that this format is easier to diff, but I tend to prefer plain readability to diff readability).

I think the main culprint here is that, as far as I understand it, there's no way to specify short collections inline.

members = [ "crates/*", "xtask/" ] turnes into

    members:
     - crates/*
     - xtask/
KenKundert commented 3 years ago

Yes, I have noticed this myself, and I have thought about ways to support inline collections. Unfortunately I cannot come up with a way of doing so that does not sacrifice the simplicity of the language. Right now everything beyond the ':␣' is a string argument and you can include any character in that string. If the language allowed inline collections, then the text beyond the ':␣' would have to be parsed and so single line strings could no longer contain characters that delimit the collections. Before developing NestedText I tried to use YAML, and this is one of the things that tripped me up.

KenKundert commented 3 years ago

One possible workaround for this limitation would be to modify the application to interpret the appropriate values as collections. For example,

members: crates/* xtask/

In this case if members were recognized as a value that is generally specified as a collection, then if it is specified as a string rather than a list, it would be split at whitespace to form the list by the end application (one can use voluptuous to do so). In this way the NestedText version becomes visually cleaner than the corresponding TOML version because all the syntactic clutter is removed.

asb commented 3 years ago

Another possibility would be to use another line type tag for inline ("flow style") collection types. In the interest of simplicity, perhaps intentionally limiting those inline collection types so they can only be on one line, and items are always unquoted and comma separated. You'd have to also consider whether to allow nested arrays or dicts.

members:
  [crates*/, xtask/]

The trade-off is obviously increasing complexity in the nestedtext format vs moving complexity to individual applications if people start implementing application-specific interpretation of strings as collections (for many applications, you'd think that attempting to parse a string that starts with a [ or a { as JSON might be reasonable).

KenKundert commented 3 years ago

At this point we are striving to keep the syntax as simple as possible and pass as much of this kind of processing to the end application.