Labelling/annotating expected items

[mikeplus64]

For a work project I'm working on it would be really nice to have a way to annotate specific expected items in ParseErrors. I'd like to be able to label expected items by the parser that they came from, e.g. "string", "number" etc.

At the moment errorCustom /kind of/ let's you achieve this, except when ParseErrors are combined you can't map specific ErrorItems to elements of errorCustom (i.e., autocompletions to labels).

[mrkkrp]

To be honest this looks like something not commonly useful, so complexity that it would introduce probably is not worth it. Nevertheless, let it hang here so if more people request such a thing, we could add it. Thanks for opening the issue.

[mikeplus64]

I think a fairly low impact way to implement this would be adding a new constructor (to ErrorItem) like:

LabelledTokens (NonEmpty Char) (NonEmpty t)

and a function that labels all "Tokens" ErrorItems, e.g. labelTokens :: Text -> Parser a -> Parser a. I'm not sure how this would look with the CPS stuff but I'm happy to give this a go.

[mikeplus64]

I think for any sort of language parser this is very useful as now you can see the category of the expected items produced e.g. "expression", "verb", "noun", "value", etc.. At the moment it's either one or the other, but both would be better IMO.

[mikeplus64]

I guess another way to implement it would be to tag errors with the SourcePos they come from.

[mikeplus64]

I'm still maintaining my own branch with this in it because it's very useful for me in production, but maybe a different design would be more palatable? I'm not sure how to implement this but:

If there was a function mapParseError :: MonadParsec e t m => (ParseError t e -> ParseError t e) -> m a -> m a that could be used here instead of changing anything. You'd just be able to take everything in errorExpected and dump it into the custom data field to achieve the same thing.

[mikeplus64]

like withRecovery, without the recovery ... :-)

[mrkkrp]

This probably may be added in some form in 5.2.0. For the upcoming 5.1.0 release I'm not adding new things right now.

---

Yeah, ParseError mapping combinator looks reasonable.

[mrkkrp]

Actually I'm thinking of adding a combinator of the type MonadParsec e t m => m a -> m (Either (ParseError t e) a). Equipped with this, you should be able to do what you need. (I.e. you match on Left, modify, and re-fail.)

[mrkkrp]

If you are OK with such a function, tell me and I'll close this issue and open another one describing that function and schedule it for 5.2.0.

[mrkkrp]

I changed my mind, this looks like a simple yet useful thing to add in 5.1.0. Closing in favor of #145.