
Type Parser a = State -> Cosumed (Reply a)

Parsec combines two data structures to return these four values:ĭata Reply a = Ok a State Message | Error Message In many cases we know that the parser consumes input long before we know that it was successful. We still have a problem - we still need to hang on to the input string until we know that the parser succeeded or failed. Edit: Thanks to Chung-chieh Shan for sending me a copy of Partridge & Wright.
#HASKELL PARSEC HOW TO#
Partridge & Wright seem to be the first to have introduced this splitting of the return value of a parse, but I can't find a non-paywalled version of their paper "Predictive parser combinators need four values to report errors." It seems like exactly the sort of paper I should be reading, but I'm also not sure on how to get in touch with the authors. There are also advantages to error reporting to making these distinctions. This limitation on backtracking means that we can drop the beging of the token-stream sooner, allowing it to be cleaned up by the garbage collector. The idea is that once a parser consumes any input (that is, looks ahead more than one charecter) we prohibit backtracking. The parsec parser, instead of returning a list of parses returns one of four results of the parse:

