1) Ideally I could parse stuff lazily. I have tried this with FTP and it is more complex than it seems at first, due to making sure you never, never, never consume too much data.
PolyParse has lazy variants of its combinators, which would probably be of use here. Software: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/polyparse Paper: http://www-users.cs.york.ac.uk/~malcolm/partialparse.html
2) Avoiding Strings wherever possible.
PolyParse is completely independent of token type. There is a rudimentary module implementing the combinators on top of ByteString. (Not currently exposed in the package interface, BTW.) I'm sure it would not be difficult to build on top of LazyByteString also. Patches gratefully accepted.
3) Avoiding complex buffering schemes where I have to manually buffer data packets.
Provided the parser is lazy enough, the buffering would be done at the level of Lazy ByteString (but I don't know whether LBS is suitable for network-reading or not).
Thoughts and ideas?
A283 SEARCH {4} {21} TEXTstring not in mailbox
Assuming the first line can be read strictly, and the remainder should be lazy, the parser might look something like this: searchResult = do n <- qnumber word "SEARCH" extents <- many1 (braces number) return SearchResult n `apply` (mapAF (\m-> exactly m char) extents) where -- embed map in an applicative functor mapAF :: (a -> Parser b) -> [a] -> Parser [b] mapAF p [] = return [] mapAF p (x:xs) = return (:) `apply` p x `apply` mapAF p xs Regards, Malcolm