[Haskell-cafe] Network parsing and parsec

Scott Turner p.turner at computer.org
Sat Sep 17 17:57:59 EDT 2005

On 2005 September 15 Thursday 12:09, John Goerzen wrote:
> However, the difficulty I come up time and again is: parsec normally
> expects to parse as much as possible at once.
> With networking, you must be careful not to attempt to read more data
> than the server hands back, or else you'll block.
> I've had some success with hGetContents on a socket and feeding it into
> extremely carefully-crafted parsers, but that is error-prone and ugly.
> Here's the problem.  With a protocol such as IMAP, there is no way to
> know until a server response is being parsed, how many lines (or bytes)
> of data to read.  Ideally, I would be able to slrup in more data as I
> go, but that doesn't seem to be very practical in Parsec either.

Assuming I've understood the gist of Koen Claessen's "Parallel Parsing 
Processes", its implementation of the Parsec interface returns all possible 
parses, in the order of how much input they consume. Also, no more input is 
consumed than necessary.  For the purpose of parsing network input, that's 
superior to the usual order in which parse alternatives are considered. The 
Parsec interface supports lookahead, which implies examining beyond what is 
consumed. That could be error-prone, but I expect lookahead is considerably 
easier to manage than Parsec's order of considering alternatives.

More information about the Haskell-Cafe mailing list