[Haskell-cafe] Need programming advice for Network ProtocolParsing

[Claus Reinke]

> 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