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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
