Differences from Parsec

Compared to Parsec 3, Attoparsec makes several tradeoffs. It is
not intended for, or ideal for, all possible uses.

While Attoparsec can consume input incrementally, Parsec cannot.
Incremental input is a huge deal for efficient and secure network
and system programming, since it gives much more control to users
of the library over matters such as resource usage and the I/O
model to use.

Much of the performance advantage of Attoparsec is gained via
high-performance parsers such as takeWhile and string.
If you use complicated combinators that return lists of bytes or
characters, there is less performance difference between the two
libraries.

Unlike Parsec 3, Attoparsec does not support being used as a
monad transformer.

Attoparsec is specialised to deal only with strict ByteString
input. Efficiency concerns rule out both lists and lazy
bytestrings. The usual use for lazy bytestrings would be to
allow consumption of very large input without a large footprint.
For this need, Attoparsec's incremental input provides an
excellent substitute, with much more control over when input
takes place. If you must use lazy bytestrings, see the Lazy
module, which feeds lazy chunks to a regular parser.

Parsec parsers can produce more helpful error messages than
Attoparsec parsers. This is a matter of focus: Attoparsec avoids
the extra book-keeping in favour of higher performance.

Incremental input

Attoparsec supports incremental input, meaning that you can feed it
a bytestring that represents only part of the expected total amount
of data to parse. If your parser reaches the end of a fragment of
input and could consume more input, it will suspend parsing and
return a Partial continuation.

Supplying the Partial continuation with another bytestring will
resume parsing at the point where it was suspended. You must be
prepared for the result of the resumed parse to be another
Partial continuation.

To indicate that you have no more input, supply the Partial
continuation with an empty bytestring.

Remember that some parsing combinators will not return a result
until they reach the end of input. They may thus cause Partial
results to be returned.

If you do not need support for incremental input, consider using
the parseOnly function to run your parser. It will never
prompt for more input.

Performance considerations

If you write an Attoparsec-based parser carefully, it can be
realistic to expect it to perform within a factor of 2 of a
hand-rolled C parser (measuring megabytes parsed per second).

To actually achieve high performance, there are a few guidelines
that it is useful to follow.

Use the ByteString-oriented parsers whenever possible,
e.g. takeWhile1 instead of many1anyWord8. There is
about a factor of 100 difference in performance between the two
kinds of parser.

For very simple byte-testing predicates, write them by hand instead
of using inClass or notInClass. For instance, both of
these predicates test for an end-of-line byte, but the first is
much faster than the second:

endOfLine_fast w = w == 13 || w == 10
endOfLine_slow = inClass "\r\n"

Make active use of benchmarking and profiling tools to measure,
find the problems with, and improve the performance of your parser.

The parse failed. The t parameter is the
input that had not yet been consumed when the
failure occurred. The [String] is a list of
contexts in which the error occurred. The
String is the message describing the error, if
any.

Efficient string handling

string s parses a sequence of bytes that identically match
s. Returns the parsed string (i.e. s). This parser consumes no
input if it fails (even if a partial match).

Note: The behaviour of this parser is different to that of the
similarly-named parser in Parsec, as this one is all-or-nothing.
To illustrate the difference, the following parser will fail under
Parsec given an input of "for":

string "foo" <|> string "for"

The reason for its failure is that the first branch is a
partial match, and will consume the letters 'f' and 'o'
before failing. In Attoparsec, the above parser will succeed on
that input, because the failed first branch will consume nothing.

A stateful scanner. The predicate consumes and transforms a
state argument, and each transformed state is passed to successive
invocations of the predicate on each byte of the input until one
returns Nothing or the input ends.

This parser does not fail. It will return an empty string if the
predicate returns Nothing on the first byte of input.

Note: Because this parser does not fail, do not use it with
combinators such as many, because such parsers loop until a
failure occurs. Careless use will thus result in an infinite loop.