-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ABNF-based Grammar #491
Comments
"let me solo her" ...unless y'all object. |
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 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 :) |
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.
The text was updated successfully, but these errors were encountered: