<div dir="ltr"><span style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px">Hi Li-yao,</span><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><span style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px">I appreciate your help especially the PR as a working fix.<span class="gmail-Apple-converted-space"> </span></span><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><span style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px">But personally I don't like the overall method of your solution, I can see Monad Transformers are powerful enough to tackle similar problems, but I'm not satisfied by the ergonomics in composing monads with transformers. `ParsecT` had already caused me much pain to get started in the beginning, and I'm still not fluent (comfortable) in transforming monads, especially I'm afraid I will have to transform much of the standard combinator functions, in order to get the real case parser working, as its resulting AST is much more complex.</span><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><span style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px">I still have faith in the improvement of megaparsec as a well known parser combinator library (I regard it as the best for engineering needs among other libraries), and I must admit megaparsec already elegantly works 99% out of my current use cases, and the very issue we are talking about  is a nice-to-have rather than must-to-have, so I would think we still have time to anticipate more options to come out.<span class="gmail-Apple-converted-space"> </span></span><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><span style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px">And I particularly like to see parser combinators have this issue addressed in its own design space.</span><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><span style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px">Thanks again with best regards,</span><br style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><span style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px">Compl</span><br><div><span style="color:rgb(255,255,255);font-family:Helvetica;font-size:12px"><br></span></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 28, 2020 at 8:19 PM Li-yao Xia <<a href="mailto:lysxia@gmail.com">lysxia@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Compl,<br>
<br>
At least, for the example you gave on this list, it can be fixed by <br>
returning Nothing instead of using the facility for failure baked into <br>
(mega)parsec. (Proposed diff for reference: <br>
<a href="https://github.com/complyue/dcp/pull/3" rel="noreferrer" target="_blank">https://github.com/complyue/dcp/pull/3</a>)<br>
<br>
"Returning Nothing" can be seen as adding a new channel for errors, <br>
turning the Parser monad into `MaybeT Parser`. Then `return Nothing` is <br>
how `empty` is defined by `MaybeT`, allowing that error to be caught and <br>
recovered from at the point where it was thrown, no backtracking. (And <br>
the original failure mode of Parser becomes `lift empty`.)<br>
<br>
Does that address your problem?<br>
<br>
Cheers,<br>
Li-yao<br>
<br>
On 10/28/2020 5:18 AM, Compl Yue wrote:<br>
> (sorry for repost, seems GMail's html processing on my last email has <br>
> rendered it barely readable, so again with plain text here)<br>
> <br>
> Dear Cafe,<br>
> <br>
> I'm still not fully clear about the confusion regarding megaparsec's <br>
> behavior that I posted lately here. But now comes to my mind that it may <br>
> have some problem rooted in the lacking of recoverability semantic with <br>
> respect to parser combinators, some quoting from <br>
> <a href="http://hackage.haskell.org/package/parser-combinators/docs/Control-Applicative-Combinators.html" rel="noreferrer" target="_blank">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 <br>
> Alternative operations.<br>
> <br>
> And `empty`'s doc:<br>
> <br>
>  > This parser fails unconditionally without providing any information <br>
> about the cause of the failure.<br>
> <br>
> Clearly `empty` is used to express failure, but there is seemingly no <br>
> device to explicitly express whether a failure is recoverable. Then I <br>
> 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 <br>
> further extended for a parser from the application, to tell the library <br>
> that some input induces recoverable failure.<br>
> <br>
> I have no expertise to suggest whether `MonadPlus` and/or `MonadFail` <br>
> are suitable devices to be considered, but as megaparsec has implemented <br>
> instances for them, I do feel some tweaks would be possible and meaningful.<br>
> <br>
> Best regards,<br>
> Compl<br>
> <br>
> <br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> To (un)subscribe, modify options or view archives go to:<br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
> Only members subscribed via the mailman list are allowed to post.<br>
> <br>
</blockquote></div>