Support BNF Variants about bnf HOT 3 OPEN

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.

from bnf.

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

from bnf.

I'm totally open to PRs 😄

from bnf.