Idea for removing / from reserved

[zkat]

I... I really am not sure this is a good idea, but I thought I'd put it here just for funsies:

We could remove / from reserved characters if we took advantage of the fact that # is reserved now, and is treated as a dispatch character:

(EDIT: single-line comments would be #!, as suggested below)

Single line comments would be #!, multiline would be #* *#, and slashdash would become hashdash #-.

With that in place, the following would become legal:

#*
this is an fstab
*#
/dev/sda1 /
/dev/sda2 /home #! home sweet home
#- /dev/sda3 /media

but:

#this is a syntax error
#"oops", you messed up, this line is also a syntax error
#true #! bool, not comment

Note that this only addresses /, so Windows paths are still screwed, but Windows supports correct slashes these days so it's probably fine.

And don't get me started about how this ship has absolutely sailed. It's probably not a ton of work to update parsers with this change but gosh it feels like some annoying logistics to suddenly push out a v3. And we should probably have a better commitment to long term stability anyway.

Previously, with credit to jax: #409

[bew]

I like this 👀

Not so sure about the #* *# for multilines, but the 2 others are great 👍

For best multiline comment, I personally love Lua's --[[ foo ]] which can support arbitrary nesting or escapes like --[=[ foo [[ no problem ]=]

So this could be #[[ multiline comment ]] 🤔

Or get inspired by markdown's backquote repetitions..
So #[ multiline ], and if you need brackets, add more around: #[[[ here [ brackets [[ no problem ]]]

[zkat]

it would still need to be #[]# because, e.g. KPath uses [] for meaningful syntax and it would be good to make sure they share a comment syntax.

[zkat]

note that /* */ already allows arbitrary nesting!

[ellieayla]

Does the above imply a shebang on line 1 would be a syntax error too?

#!/usr/bin/env kdl

[bew]

If we start re-purposing #, it might open the way for #! ... markups, and allow #!/... as valid 🤔

[tabatkins]

We'd probably just define that #! is an alternate single-line comment syntax.

[zkat]

lol that would actually be hilarious.

[tabatkins]

I agree that this is quite a change to justify a v3 so quickly, but also... I like it? Relying on # as the general meta-dispatch character for everything is pretty clean, and it means our single-line comments match Python rather than JS, which is a perfectly acceptable lateral move. (It also matches YAML and TOML.)

As I say in another comment here, I think we'd accompany this move with a declaration of #! as another line-comment syntax, to allow shebangs, which is nice.

[zkat]

I think if we coordinate things right, we can shift everyone over to "KDL RFC" mode, and declare the KDL RFC as a distinct language from KDL v2, and deprecate v2 since it has relatively little reach right now?

I feel really uncomfortable making such a huge change at all, but it... seems genuinely really valuable?

[jaxter184]

On one hand, I agree that the ship has sailed. On the other hand, this is a really nice solution that I like more than any of the solutions I proposed, and I think if enough of the users/implementers think this is worth it, it could be worth the friction to make KDL more ergonomic? For one, most URLs would be valid bare identifiers.

[tabatkins]

Yeah, impl-wise it's a trivial change, so we could do the cutover real quickly.

[zkat]

I've also created a team so we can very quickly ping all implementers about stuff like this.

[zkat]

I posted #496 about how to handle this change and other similar moments of brilliance in the future

[zkat]

Another thought I had about this. Consider these two examples:

https://example.com#!anchor
random-string#!oops I forgot a space before #!

So our choices seem to be:

1. Make #! the line comment character in which case people who paste URLs into KDL risk having their anchors silently stripped

2. Allow NON-INITIAL # in unquoted strings, but then if someone neglects to put a space after an unquoted string, the entire comment will be slurped into the string value

3. Specifically disallow #! in unquoted strings, which means pasting that link will be "safe" (syntax error, need to quote), and you can't inadvertently forget to put a space before the #! and have it get slurped in.

My main concern with 3 is that it's a very subtle nag that requires a bit more detailed knowledge of the language. It would work in like 99.9% of cases. I'm just worried about how materially frustrating and disruptive the other cases will be, and whether this means users will make a habit of scanning their URLs for #!. This can be hugely alleviated by syntax highlighting and diagnostics, of course, but I think anyone should be able to open notepad and do the right thing.

Thoughts?

[zkat]

Yeah that's definitely a footgun now but also I kinda don't feel like that's as likely as "I copied a random URL from my browser".

[zkat]

Ugh now I'm brain wormed about how many people are going to suffer because of foo=bar and I'm trying not to regret unquoted strings. 🫣

I hope it never happens in practice

[tabatkins]

Unquoted strings are a huge win, don't worry. Unquoted attributes are great in HTML too, and they can have similar issues; you just learn to reflexively quote anything "weird", it's fine.

[zkat]

@tabatkins ohhhhh actually that's right. I did remember unquoted attributes in HTML but I thought KDL would be different because it has both properties and arguments... but HTML has name-only boolean attributes, too, which effectively have the same issues.

[tabatkins]

Well, HTML boolean attrs are just the attr name, not the value, so by convention they're just simple ascii alphanums anyway and not troublesome. But I definitely put "simple" urls into attributes unquoted, but immediately reach for the quote characters as soon as there's params or anchors or anything else weird.

[bgotink]

I'm… not convinced this is a good idea. We now have four significant characters in the syntax: {} to group stuff, # is used in values and / is used in comments. (oh and \ exists as well, doing it's usual thing)
Having different characters for comments and values is imo a good thing. Using # for both values and comments makes things imo a whole lot more confusing.

As an example, we explicitly require space between all values, but not between values and comments.
So this would be a valid document:

node #"value"##* comment *##"value too"#

That's a few steps back from what we currently have

node #"value"#/* comment */#"value too"#

Another example, I'm working on a document

node "value" \
  #"raw\ value"#

and I want to comment "value" but I make a mistake and forget the -

node #"value" \
  #"raw\ value"#

is a valid document. The same can't be said for me forgetting the - in /-.

If I wrote

node #"value"
  #"raw\ value"#

did I forget to add a ! after the first #? Did I forget to escape a newline? Did I forget to use """ for a multiline string? Did I forget a # after #"value"?
Error messages will have to become more unhelpful if we implement this proposal.

---

This doesn't feel like an improvement to me. Yes, it buys us the / character for identifiers so I can write many—but not all—URLs and UNIX-style paths without quotes. I'm not sure this new syntax is a price I'd be willing to pay.

[zkat]

yeah I'm... I think I'm pretty convinced this is not a good idea, at this point. It was worth discussing, but woof, some of those cases.

[jaxter184]

Hmm yeah, these examples are pretty rough. Hopefully we can consider other options in the future for a V3 or RFC edition (maybe considering options other than # for the boolean/raw string character?), but this and the #!anchor examples have convinced me that the "simple and quick" fix seems to be more fraught than I initially thought, and have brought my hopes back down to manageable levels.