Macro Constructors

[CrockAgile]

What

Adds macro constructors for each of the base BNF types (terms/expressions/productions/grammars)

let dna_grammar = bnf::grammar! {
  <dna> ::= <base> | <base> <dna>;
  <base> ::= 'A' | 'C' | 'G' | 'T';
};

How

Via not very easy to read, and hard to test macro_rules 😅

Why

• sometimes writing a macro is nice because it is shorter than <prod> ::= 'A'".parse()
• it is definitely shorter than the *::from_parts constructors

Why Not

• macro_rules are hard to reason about, debug, and test
• maybe offering multiple ways to do the same thing is confusing to users
  • for example, because whitespace is not a token, semicolons are a hard requirement for parsing a Grammar via macros

Future Dreams

The main motivation for this was to see if maybe a const constructor would be possible. The current macros do not support that due to vector mutations, but I think it may be doable. Unfortunately, a full macro const constructor would require:

• Terms to hold Cow<str>, not String
• Grammar/Prod/Expression would need to hold Cow<[T]>, not Vec<T>

This is doable, but would definitely introduce many breaking changes.

Open Questions

• is this more useful than confusing?
• is the future dream of a const constructor worth breaking changes?

[coveralls]

coverage: 98.283% (+0.06%) from 98.228%
when pulling bdde346 on macro-constructor
into 4b433e8 on main.

[CrockAgile]

maybe this warrants moving all macros to their own mod ?

[shnewto]

oh wow! first impression is that it's a very cool concept and the dream of a const constructor is one I'd like to see realized too ❤️
i appreciate the why nots laid out, requiring semi-colon's is probably what gives me the most pause... I sort of want to think about that bit some more in case there's something we could do to live without them... like maybe just make newlines optional in grammars altogether?

[shnewto]

also I wonder if something like like maud or inline-python are doing something interesting to parse significant whitespace?