On 18 October 2010 07:56, Magnus Therning
AFAIK Parsec deals with String, not ByteString, have a look at the attoparsec library[1] instead.
From the original post, the syntax of what is to be parsed looks simple (essentially a single data type, no alternatives except the AccessType tag), so it can probably easily get by without combinators
Parsec 3.0 deals with ByteStrings, Parsec 3.1 and higher improve the performance quite about. like sepBy and endBy. It would need a sample of the input data or a grammar for it to affirm this, though. A working (simple) parser in Parsec should be easy to convert to Attoparsec etc if it doesn't use combinators like sepBy. parseEvents :: Parser [Event] parseEvents = many event event :: Parser Event event = do fn_ <- parseFn mft_num <- parseMftNum ft_ <- parseFt fs_ <- integer time_ <- integer at_ <- parseAccessType mt_ <- parseAccessType ct_ <- parseAccessType crt_ <- parseAccessType return $ Event { fn = fn_ , mftNum = mft_num , ft = ft_ , fs = fs_ , time = time_ , at = at_ , mt = mt_ , ct = ct_ , crt = crt_ } More parsers will need to be defined for parseMftNum etc. The applicative style as used in RWH can get rid of the interim variables which makes it much nicer for parsing than the monadic style. Parsec 3.0 and later can use the Applicative style. How the input data separates fields will need taking care of.