fifty-nine / grune Goto Github PK

The sentence_iterator class isn't a template, so most/all of its implementation could be moved to the .cpp file to reduce TU dependencies.

Currently, everything passed to a grammar needs to stay valid for the lifetime of the grammar. We should rework things so that the grammar owns everything.

Once we fix #9, it will probably be a little more unwieldy to instantiate a grammar. We should implement an EDSL for creating grammars, c.f. the builder pattern.

We need a way to identify some properties of an arbitrary grammar, e.g., what Chomsky type is it?

Productions aren't symbols, so they definitely shouldn't specialize symbol_traits.

grune::production takes a sequence_list as its right-hand side. It might make things simpler if we only allowed a production to map from a sequence to a sequence, but allowed multiple productions with the same left-hand side.

We need a way to have terminals that match a regular expression. We could probably represent them using the existing grammar model nested under a new terminal subclass, or we could use a purpose-built regular expression library that meets the requirements of both parsing and generating sentences.

We should add a new library for parsing the grammars modeled by the library. The library should include at least one basic parser. The library should probably support both runtime parsing and code generation, though not necessarily with the same parsers. This would probably make sense to put in a separate github project.

We should probably remove the specialization of symbol_traits for symbol. Instead, we should provide overloads of the relevant free functions (to_string, is_terminal, etc.)

We should add some static assertions about properties of the classes in the type hierarchy. E.g., grune::symbol should be default constructible, copy constructible, etc.

Currently a number of the constraints in check.cpp do not require the nothrow property. A lot of them could probably be strengthened to include it.

Currently the only way to print a grammar is by calling to_string, which returns a simple EBNF-like syntax. We should add additional pretty print formats, especially ones that are easily machine-readable, e.g. YAML, JSON and/or XML.

We should add exceptions for when the user tries to create an invalid grammar. For instance, it's possible to create a production with only terminals on the left.

We should add a way to load grammars from a machine-readable text format, preferably the same as in #4.

We should add an interface to generate a sentence from a grammar. Since the algorithm for generating every sentence from a grammar is exhaustive, I think this might make sense as a forward iterator.

The interface could look something like:

for (auto sentence : grammar.sentences()) 
{
  cout << to_string(sentence);
}

Note that generating even a single sentence from a Type-0 grammar is potentially unbounded, so maybe we should provide a different interface for letting the user acknowledge that, but still try to generate sentences.

Add a parser for EBNF grammars.