make support for raw and multiline strings optional in KQL

[lolbinarycat]

I am writing a KQL implementation in rust, and I am using parser combinators to ensure things match the spec as closely as possible.

The "non-greedy repetition" that is described in the grammar doesn't even seem to be a fully coherent operation within a recursive decent parser without backtracking.

The utility of these syntactic constructs within kql seems questionable at best, and it would greatly simplify implementation.

[tabatkins]

I don't think we should encourage language impls that don't support KDL. If you would like to document that your KQL tool doesn't support those language features, that's just fine; they might indeed not be very useful for you. But in general, KQL documents are KDL documents and should have the same syntax.

A little more confusingly to me, KQL is designed to let you query a KDL document. If you're writing a parser that can't easily support these string types, how are you planning to handle KDL docs that include them?

[lolbinarycat]

The KQL impl i'm writing pulls in a seperate KDL impl which doesn't expose its AST or parsers.

[zkat]

kdl-rs is also written with a parser combinator library. It handles the backtracking just fine imo

[zkat]

https://github.com/kdl-org/kdl-rs/blob/main/src/v2_parser.rs#L1253-L1366 Here’s the raw string impl

[lolbinarycat]

Guess I have to just write a repeat_till combinator?

Even without that, these two parsers together would be half the size of all my current parsering logic combined.

Doesn't exactly refute my point about complexity.

[xpe]

Even without that, these two parsers together would be half the size of all my current parsering logic combined. Doesn't exactly refute my point about complexity.

Your point, as I understand it, is to request a change to the language where a primary motivator is to make implementations easier.

Personally, I very much value KDL's emphasis on human-workability. One can search far and wide for data languages that:

1. handle multiline strings well.
2. offer convenient ways to write raw strings.
3. are sane to parse

Here's my summary:

format	multiline?	raw string?	parsing complexity
JSON	❌	❌	🍰
JSON5	❌①	❌	🍰
KDL	✅	✅	🍰
TOML	✅	✅	⚙️
RON	✅	✅	⚙️
XML	✅	✅②	🌶️🔥🚽③
YAML	✅	❌	🌶️🔥🚽④

• 🍰 simple
• ⚙️ moderate
• 🌶️🔥🚽 call the doctor
• ① line continuation \ doesn't count in my book
• ② <![CDATA[...]]>
• ③ context-sensitive
• ④ context-free with a large spec

[lolbinarycat]

@xpe you seem to be under the impression I am requesting a change to KDL, not KQL. A fair comparison would be between jsonpath or XPath, neither of which support multiline or raw strings according to my cursory research.

[xpe]

@xpe you seem to be under the impression I am requesting a change to KDL, not KQL. A fair comparison would be between jsonpath or XPath, neither of which support multiline or raw strings according to my cursory research.

Whoops. Sorry about that.