Create combinator for multiple failures about megaparsec

[mrkkrp]

Should be absolutely doable. I'll see how to include it in existing code smoothly. Thanks for the idea.

[recursion-ninja]

I imagine a new parserFailures primitive which extends the existing parserFail/fail and is structurally similar to the way labels extends label/(<?>).

parserFailures could then be aliased as fails or require the un-aliased, verbose invocation.

[mrkkrp]

This will be implemented in version 4.2.0. More general method will be added to MonadParsec that will allow to fail with arbitrary collection of error messages (Expected, Unexpected, and simple Message). Then we will define unexpected and fails (maybe it will be called differently) in terms of this more general method.

---

Note to self: Text.Megaparsec.Error should have functions to:

• add arbitrary list of messages to existing ParseError;
• create new ParseError from existing list of error messages.

[mrkkrp]

@recursion-ninja, This is now possible. fails is not defined by default, because I think it won't be often used. Instead you have failure:

failure :: MonadParsec m => [Message] -> m a

This allows to fail with arbitrary collection of messages. You can define fails in terms of failure, like this:

fails :: MonadParsec m => [String] -> m a
fails = failure . fmap Message

Hope it helps.

[recursion-ninja]

I look forward to using the failures combinator in our codebase.

We transitioned from Parsec to Megaparsec last week and everything went smoothly (all the tests passed). The error messages are noticeably better, and since we are optimizing our parsers for error clarity and not speed, Megaparsec has proved to have been the right choice!

Thanks for your wonderful work!

[mrkkrp]

@recursion-ninja, Thank you. failures will be available in 4.2.0 which will be released by December approximately.

[recursion-ninja]

The failure combinator only allows for a list of disjoint errors (logical or) and not conjunctive errors (logical and). Say I wanted to say that there are 2 (or more) things wrong with the stream I am parsing, such as an 'A' is missing and there are too many 'B's.

ghci let fails = fails = failure . fmap Message
ghci> parse (fails ["I am missing an 'A'","I have too many 'B's"] <* eof) "" ""
Left 1:1:
I am missing an 'A' or I have too many 'B's

The rendering here is quite misleading, I have both errors, not one or the other (most people read plain English 'or' as logical xor). Is there a way to allow for a Message type which denotes multiple conjunctive errors which can be rendered with 'and' conjunctives in the plain text?

Perhaps something like this:

import Data.List.NonEmpty
data Message = Unexpected String
             | Expected   String
             | SingleMessage    String
             | Composite Message (NonEmpty String)

The use case is when parsing in a Monadic context and upon inspecting the partially parsed data discovering the parsed data to be invalid in multiple ways simultaneously. Simply concatenating the error messages into a longer String before passing that to fail feels incorrect because there isn't one failure, there are many.

Do you think a "composite error" type is a useful addition, or beyond the scope of MegaParsec?

[mrkkrp]

I don't think “composite” error messages are good idea in this form. With unexpected and expected message components it's always about logical or. It would be quite strange to output something like:

unexpected 'a'
expecting 'b' and 'c'

We cannot expect b and c at the same time.

It's different with messages, because they are really collection of statements, so several of them can be true at the same time. I think I'll just fix rendering of Message in showMessages, so every message is printed on separate line without any “ands” or “ors”. This should solve the problem.

[mrkkrp]

@recursion-ninja, Fixed in 8ea4ebe.

[recursion-ninja]

That solution seems better, without conjunctives 'and' or 'or' in the rendering, the relations between many Messages will appear independent, which is all the parser state can reasonably assume about them.