5

When using the <|> combinator in a Parsec or Megaparsec parser, 'try' maybe needed to force backtracking in case the first parser fails having consumed input. In Parsec I need to use 'try' when parsing strings:

λ: parse (try (string "abc") <|> string "abd") "" "abd"

Right "abd"

Without the 'try', the parse fails as the first parser consumes the 'a', leaving just 'bd' for the second parser which then naturally fails as well.

In Megaparsec, the 'try' is not needed:

λ: parse (string "abc" <|> string "abd") "" "abd"

Right "abd"

and so somehow in Megaparsec the string parser helpfully does not consume input when it fails.

My questions are:

  1. How might I have found out, other than experimenting, that the string parser behaviors are different between Parsec and Megaparsec - I have no seen it documented?

  2. How can I easily (that is, without experimentation) tell in general whether a parser consumes input if it fails?

Thank you.

  • 3
    At least for megaparsec, this is documented right in the haddocks for `try` and `string` (the latter links you to `tokens`, which has the full explanation)... – HTNW Jan 18 '21 at 01:26
  • Thank you HTNW. I have now found the required documentation as you indicated. This effectively answers my question (1) above. With this knowledge I can also quite easily determine if a parser, whether built in to Megaparsec or constructed myself, may need 'try' applied, so that answers (2) as well. – New England Jan 18 '21 at 07:37

0 Answers0