Some snippets from the Tutorial [1] to give an idea of the
grammar-combinator library's approach, its functional style and its
additional power (e.g. the transformations used):
Defining a simple expresssions grammar:
grammarArith :: ExtendedContextFreeGrammar ArithDomain Char
grammarArith
.. grammar-combinator library's approach ..
am I reading this correctly: in the traditional combinator approach,
a grammer (a parser) is a Haskell value,
while in your approach, the grammar is a Haskell (GAD)type?
then you'll get more static guarantees (e.g., context-freeness)
but you need
On Sep 8, 2010, at 7:49 AM, Johannes Waldmann wrote:
then you'll get more static guarantees (e.g., context-freeness)
but you need extra (type-level, or even syntax-level) machinery
to handle grammars. Convince me that it's worth it ...
Those guarantees, along with just the fact that the
That compilation process is highly nonlocal
and would never be possible with, e.g., the Parsec approach.
Pipe dream: attach such a grammar object to every Parsec parser,
and include the compiler with the combinators,
and have them run at (Haskell) compile time (in ghc's specializer).
Should
Johannes,
(sorry for the double mail)
I will give some short answers below, but you can find more details in
the paper we are submitting to PADL 2011 [1].
2010/9/8 Johannes Waldmann waldm...@imn.htwk-leipzig.de:
.. grammar-combinator library's approach ..
am I reading this correctly: in the
Johannes,
2010/9/8 Johannes Waldmann waldm...@imn.htwk-leipzig.de:
That compilation process is highly nonlocal
and would never be possible with, e.g., the Parsec approach.
Pipe dream: attach such a grammar object to every Parsec parser,
and include the compiler with the combinators,
and
