When I try to parse many p
, I don't receive the 'expecting p' message:
> parse (many (char '.') >> eof) "" "a"
Left (line 1, column 1):
unexpected 'a'
expecting end of input
Compare to
> parse (sepBy (char '.') (char ',') >> eof) "" "a"
Left (line 1, column 1):
unexpected 'a'
expecting "." or end of input
which reports "." as I'd expect. many1 p <|> return []
works as well.
All of these functions accept empty input, so why doesn't many
report what it's expecting? Is it a bug or a feature?
In a somewhat superficial sense, the reason for the difference in behavior is that many
is a primitive parser whereas sepBy
is constructed in a similar manner to your reimplemented many
. In the latter case, the "expecting..." message is constructed based on alternatives that were available along the path that led to the parse failure; with many
there were no such choices, it merely succeeded unconditionally.
I don't know that I'd describe this as either a bug or a feature, it's just sort of a quirk of how Parsec works. Error handling is not really Parsec's strength and this really doesn't seem like the first thing I'd worry about in that regard. If it bothers you sufficiently you may be better served by looking into other parsing libraries. I've heard good things about uu-parsinglib, for instance.