Support BNF Variants

[hbina]

Is your feature request related to a problem? Please describe.
Most uses of BNFs out there are not formal i.e. they are meant to be human readable. As such, they contain non-standard features such as optional. For instance, consider this RFC that does not use standard BNF to describe Preferred Name Syntax for DNS

Additionally, are you interested in supporting EBNF and validating a given input.

Describe the solution you'd like
I would like to have these features. I am not sure how fine the configuration can be done. Not sure entirely how this is done in Rust but if its like #ifdef in C then I think its fair to want the code to be readable.

Describe alternatives you've considered
I think all of these features are expressable in terms of standard BNF. So users can always make that manual transformation.

Additional context
I needed this while trying to validate (Another feature I want) a given string with the BNF from above. See Wikipedia's page for BNF Variants

1. https://tools.ietf.org/html/rfc1035#section-2.3.1
2. https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form#Variants

[shnewto]

Hey @hbina thanks for raising an issue! It sounds like you're asking a couple things, one is for some extended syntax support and another is for the code to be more readable? I'm definitely interested in extending this library to support EBNF syntax, there's been some prior efforts here #54 but I'm not sure what the status there is. If there's something outside of what EBNF covers that you'd like to see, it'd be great if you were able to list it here for me.

As for readability, if there's specific areas where you feel there are issues I'm happy to tackle it if you'd list that here too.

Fwiw, I think I like the idea of extending the lib without needing to compile with feature flags (i.e. #[cfg(feature = "ebnf")]). I started a conversation awhile ago about what I'd imagined EBNF support might look like here #17

[hbina]

I wasn't commenting on your codebase readability when I mentioned it. But I was wondering how complicated would have to be to be able to support complicated configurations i.e enabling A and C but not B and D. Therefore, if this proves to be too complicated, requiring major overhaul, then I think there is a point to keeping it simple.

However, since you mentioned it, I think its worth it to try to use the lingo used by ISO 14977 for EBNF in the codebase + some documentation and possibly exposing the parser API.

If you are open to PRs I am already trying to work on this. I think the parser code have lots of duplication. I am also trying to add validation as a feature.

[shnewto]

I'm totally open to PRs 😄