Are you someone who really likes dealing with language grammars and understanding their corner cases? Could I interest you in giving the #kdl v2 grammar a quick look-see and seeing if there's anything particularly dysfunctional about it? We're looking ...
-
Are you someone who really likes dealing with language grammars and understanding their corner cases? Could I interest you in giving the #kdl v2 grammar a quick look-see and seeing if there's anything particularly dysfunctional about it? We're looking at releasing the final version very soon, and I'd like more eyes on it.
https://github.com/kdl-org/kdl/blob/fa204cec62abef085e33af65f849994846ae68a6/SPEC.md#full-grammar
-
@zkat oh yeah sure, we DO enjoy that. let us take a look after our meetings
-
@irenes thank you!
I like to think I'm pretty good at parsing/grammars, but I don't have full academic knowledge about it, and I miss corner cases when designing them sometimes (and I usually just stomp them out as I run into them).
But I want to make sure this one is solid. It's already gotten a lot of eyes on it, but if the grammar itself can be cleaner/improved, then that will be worthwhile.
-
@zkat okay, please hold for stream of consciousness as we work our way through the spec...
-
@irenes would it be more practical to comment directly on the v2 PR? https://github.com/kdl-org/kdl/pull/286
-
@zkat intermingling named parameters with by-order parameters is an interesting choice; most programming-centric languages that have both put the by-order parameters first. we do agree that the analogy to command lines may help it feel natural, though we also note that it's fairly common in that context for the by-order parameters to have to go LAST (the opposite...). we could imagine it being confusing for beginners to read. in fact, we could imagine that confusion being quite substantial.
-
@zkat we can try if you want to... our thoughts come out more easily if we stream them in small chunks
-
@zkat the type annotations thing is nice and we like that. we're glad it's explained with an example, because the terminology is a little confusing. that isn't what you asked for feedback on though, so we'll move on
-
@zkat we're huge fans of slashdash. reminds us of a Common Lisp feature. it's very useful in rapid development.
-
@zkat the two-kinds-of-descendants thing (parameters vs. children) is similar to sgml/html/xml and, eh, it's probably fine. it's kinda fundamental to the design and we do think you should go ahead with it. we were never 100% about it even in html, but over the years it hasn't really been a cause of trouble.
-
@zkat line continuations will be a big pain if the format ever puts users in the situation of needing to care that a block of text is a single node vs. many nodes. do everything you can to make sure they don't have to worry about it.
-
@zkat since you seem to be aiming more at configuration tasks than at user-facing-document kinds of things, that may be okay.
-
@zkat allowing the four kinds of equals sign is an interesting choice. we do see the i18n motivation and think it's reasonable.
you do not, under any circumstances, want to get into a situation where different implementations allow different sets of equals-sign characters; that could be exploited to hide malicious input from one layer of processing while exposing it to another, a common problem with http header parsing. make sure the wording is firm about the security need to not extend them.
-
@zkat including newlines in quoted strings is probably a good call, it will mitigate the thing we mentioned above about blocks of text.
treating identifiers as a type of string is interesting, especially because type annotations are identifiers but they have some sub-structure in how they're used, with the parenthesized part. we recommend formalizing some syntax around the parentheses in type annotations (look at the Rust annotation syntax for inspiration) rather than making it free-form.
-
@zkat wait, let us get to the grammar for this.... you did do something there, it just wasn't obvious yet
-
@zkat good call forbidding control characters
-
@zkat we also like your handling of line endings
-
@zkat okay, you did get it right with U+FEFF, we were slightly concerned about the impact on emoji "ligatures" but they turn out to be unaffected. good.
-
@zkat are you certain you want to forbid bidi text? if people are writing blocks of text which mix languages, they may have a genuine need for the bidi markers
-
@zkat we realize that failing to handle bidi at the application layer introduces vulnerabilities, but it's still an important feature