I'm looking for help to finish tests sooner about megaparsec

[mrkkrp]

I think I will start writing tests for Text.Megaparsec.Perm — permutation parsers. The module is quite minimal and at the same time not everyone is familiar with the concept of permutation parsers, so I think it's easier for those who wish to help to concentrate at Text.Megaparsec.Combinator module, since all combinators in that module are straightforward.

[mrkkrp]

Interestingly, there seem to be some code implementing applicative interface to Parsec permutation parsers, and it comes with QuickCheck tests. I need to study the code to decide if we should ask the author of the code whether it's possible to use it in Megaparsec, possibly with some changes.

[mrkkrp]

No, that code cannot be used. Parsec's permutation parser is integrated with the rest of the library, while this thing invents its own collection of combinators like optionPerm, manyPerm, etc. Also its tests don't use the power QuickCheck provides, they don't have any varying arguments!

My conclusion is to leave Text.Megaparsec.Perm as is and write collection of truly generative tests for it.

[mrkkrp]

I've found writing tests for Text.Megaparsec.Perm non-trivial. At least if we want good tests. Currently I have to use custom data types to generate arguments for tests together with input for parsers. This will take longer to finish than I expected.

In addition to that it seems like error messages suck again. For example that example from documentation produces strange error messages:

p = (,,) <$?> (a', some (char a))
         <||> char b
         <|?> (c', char c)

QuickCheck generates the following values:

• a' = ""
• a = '?'
• b = '!'
• c' = 'a'
• c = '='

And input for the parser is ?.

Current implementation says:

Left line 1, column 1:
unexpected '?'
expecting '!' or '='

Wrong, it should be:

unexpected end of input
expecting '!'

because one '?' is enough for some (char '?'), but char '!' needs also a '!'.

It seems like this thing could use applicative interface, implemented in a decent way.

[mrkkrp]

Now I see that without tests for Text.Megaparsec.Combinator we cannot move forward to test more advanced parts of the library, since we cannot know whether it's combinators that don't work (produce low-quality error messages) or something built on top of them. I'm closing this request and going to test non-primitive combinators.