[Haskell-cafe] Consider adding recoverability to the vocabulary of parser combinators

[Compl Yue]

Dear Cafe,

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
http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicative-Combinators.html

The  *A note on backtracking* section

> Combinators in this module are defined in terms Applicative
<http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Applicative>
 and Alternative
<http://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#t:Alternative>
 operations.

And `empty`'s doc:

> This parser fails unconditionally without providing any information about
the cause of the failure.

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:

*) a failure with no input consumed can be recovered by rest parsers
*) a failure with some input consumed can not be recovered by rest parsers

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.

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.

Best regards,
Compl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20201028/730f1286/attachment.html>