<div dir="ltr"><div>(sorry for repost, seems GMail's html processing on my last email has rendered it barely readable, so again with plain text here)</div><div><br></div>Dear Cafe,<br><br>I'm still not fully clear about the confusion regarding megaparsec's behavior that I posted lately here. But now comes to my mind that it may have some problem rooted in the lacking of recoverability semantic with respect to parser combinators, some quoting from <a href="http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicative-Combinators.html">http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicative-Combinators.html</a><br><br>The  *A note on backtracking* section<br><br>> Combinators in this module are defined in terms Applicative and Alternative operations.<br><br>And `empty`'s doc:<br><br>> This parser fails unconditionally without providing any information about the cause of the failure.<br><br>Clearly `empty` is used to express failure, but there is seemingly no device to explicitly express whether a failure is recoverable. Then I observed megaparsec's implicit rule as currently implemented is like:<br><br>*) a failure with no input consumed can be recovered by rest parsers<br>*) a failure with some input consumed can not be recovered by rest parsers<br><br>This works to great extent, but I would think the expressiveness can be further extended for a parser from the application, to tell the library that some input induces recoverable failure.<br><br>I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` are suitable devices to be considered, but as megaparsec has implemented instances for them, I do feel some tweaks would be possible and meaningful.<br><br>Best regards,<br>Compl<br><div><br></div></div>