satisfyWith, skip, scan, and most of the numeric parsers are
not yet implemented. Patches are gladly welcome!

Parsec parsers (and hence the parsers provided here) do not automatically
backtrack on failing alternatives that consumed input. With careful use
of try it is possible to write parsers that behave consistent across
Attoparsec and Parsec. Read the next section for more on that.

Writing parsers that behave consistent across Attoparsec and Parsec

Some care is needed, so that parsers behave consistent across
Attoparsec and Parsec in regards to backtracking. Attoparsec parsers always
backtrack on failure. In contrast, a Parsec parser that fails after it has
consumed input will not automatically backtrack, but it can be turned into
backtracking parsers with try.

Here is an example that illustrates 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.

The try function can be used to write parsers that behave consistent
across Attoparsec and Parsec. Each alternative that may fail after
consuming input, has to be prefixed with try. E.g. for the parser above
we would write:

try (string "foo") <|> string "for"

For Parsec try enables backtracking, for Attoparsec it's just a
type-constrained version of id (see Attoparsec's try).