KQL is very restrictive in where you can put comments

[lolbinarycat]

according to the grammar, all of the following are invalid queries:

foo // comment

foo /* comment */ [bar]

/* comment */
foo

foo[ // comment
bar]

[zkat]

Yeah KPath (née KQL) is due for some serious work in general.

Although one must wonder if a language like this should even support comments

[lolbinarycat]

I think the fact it has 7 different types of string literals is a much larger chunk of semantic complexity.

[zkat]

KDL has 3 different string literals, 2 of which have multiline variants with otherwise identical syntax. Where are the other two? I'm not sure what you're getting at.

I can see how comments can be useful in practice, though. And I mean, CSS selectors do, apparently. TIL you can literally comment selectors that you pass to document.querySelector! It had never occurred to me to do so lol.

[lolbinarycat]

1. ident string
2. signed ident
3. dotted ident
4. quoted
5. raw quoted
6. multiline
7. raw multiline

each of these requires their own code path in the parser unless you get really clever about it.

[zkat]

ah, you split idents into different kinds. That's mostly an implementation detail, but ok.

[lolbinarycat]

I mean, I am speaking from the perspective of an implementor, so I am very much concerned with implementation details.

[tabatkins]

This discussion is definitely a digression, but: speaking as an implementor as well, most of those variations aren't meaningfully separate types to me. I have three string-parsing functions, for handling idents, quoted, and multiline. The other variations are just that - variations within those parsing functions.

None of that is relevant to a discussion about comments in KPath, tho.

[zkat]

I think the bit that matters here, and what I believe @lolbinarycat is getting at, is that since we have a certain level of complexity with strings, therefore any other level of complexity becomes acceptable.

Assuming this is the line of argument, I would caution against it. Whatever the complexity or simplicity of a feature, I think we should do what we've always done: steer away from complexity when we can, and discuss the cost-value situation in those cases, as individual cases.

To move this specific conversation forward: all of your examples seem reasonable to me, except the 4th one would not follow from the conventions we've set forth for spaces inside (...) in KDL. This seems worth including/supporting as part of the (ongoing) KPath overhaul

[lolbinarycat]

This discussion is definitely a digression, but: speaking as an implementor as well, most of those variations aren't meaningfully separate types to me. I have three string-parsing functions, for handling idents, quoted, and multiline. The other variations are just that - variations within those parsing functions.

If you are using handwritten or tokenization based parsing, I'm sure you can use a clever workaround to collapse this into one function, but if you want to write a contaminator based parser that closely follows the spec, there are several combinators that are used solely for raw strings.