kdl
kdl copied to clipboard
kdl-org
ABNF-based Grammar
I think it would be good to convert our current grammar to ABNF, even if we might need to make some notes about cuts/greediness.
It's gonna be a bit of a hassle, but I think it's going to be more in line with the expectations for RFCs. And tbh I don't entirely mind moving away from our fun little frankenstein, even if it'll be more verbose.
It's not something I've done extensive research on just yet, but it would be interesting to compare a couple of different ABNF vs EBNF things perhaps?
In the past I've used the ISO standard EBNF to generate really nice documentation / interactive railroad diagrams with this tool: https://matthijsgroen.github.io/ebnf2railroad/try-yourself.html , but, that ISO standard also kinda sucks: https://dwheeler.com/essays/dont-use-iso-14977-ebnf.html
I know essentially nothing about ABNF, but I saw mention of some strange case insensitivity? https://stackoverflow.com/a/29875840 (Though now that I think about it, I suppose that won't matter for KDL itself — perhaps for the schema stuff?)
That's all to say that, personally, if I were rewriting the grammar, I'd pick the exact EBNF / ABNF version that is supported by the automated tools you want to use! :)
The advantage of ABNF is that it’s the primary grammar language for IETF RFCs (as defined in RFC 5234).
The main challenge with ABNF is that it’s going to be a bit more verbose in a few places because you can’t just do the - thing that we use a lot. We would need to have a lot of smaller productions and combine them piece by piece for the different cases instead. And yes, you can work around the case sensitivity pretty easily with the %s prefix.
The only things we do that ABNF does not have are the cut and the non-greedy parsing, but I think we can just use comments and/or prose to specify that. ABNF isn’t a regex engine, after all.
I think that's a really good argument for ABNF then! I'll have a look around for any tools that could play nicely with it in case we're ever interested :)