I'm occasionally working on making a friendly yet performant library that simultaneously builds parsers and generators, but it's non-trivial. If you

I'm probably missing something in the "friendly yet performant" requirements, but I never quite understood the difficulty: A typical translation of grammar to parser combinators has very little code specific to "parsing" - it is mostly encoding the grammar in a coordination framework that calls on literal parsers at the bottom. Since the coordination framework uses some form of state transformers, exchanging the literal parsers with literal unparsers should turn the grammar parser into a grammar unparser (in essence, the non-terminal code is reusable, the terminal code is specific to the direction of data flow). Add switch-points (where the "mode" can switch from parsing to unparsing and back), and one has syntax-directed editors (here you need to be able to restart the process on arbitrary non-terminals), or expect-like protocol-driven computations (two or more agents with complementary views of which parts of the grammar involve parsing and which unparsing). The non-trivial parts I remember are to ensure that the unparser is directed by the AST (unless you want to generate random sentences from the whole language), just as the parser is directed by the input String, and not biasing the combinator framework towards parsing (which happens all too easily). But then, it has been a long time since I wrote such parser/unparsers (the first before Monads and do-notation became must-have aspects of combinator parsers, when we were free just to "make it work";-). It would be useful to have an overview of the issues that lead to the widespread view of this being non-trivial (other than in the narrow interpretation of "non-trivial" as "needs some code"). I've always wondered why there was so much focus on just parsing in combinator libraries. Just curious, Claus