New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Labelling/annotating expected items #111

Closed
mikeplus64 opened this Issue Jun 23, 2016 · 10 comments

Comments

Projects
None yet
2 participants
@mikeplus64

mikeplus64 commented Jun 23, 2016

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

This comment has been minimized.

Owner

mrkkrp commented Jun 25, 2016

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

This comment has been minimized.

mikeplus64 commented Jun 28, 2016

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

This comment has been minimized.

mikeplus64 commented Jun 28, 2016

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

This comment has been minimized.

mikeplus64 commented Jul 4, 2016

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

@mikeplus64

This comment has been minimized.

mikeplus64 commented Sep 26, 2016

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

This comment has been minimized.

mikeplus64 commented Sep 26, 2016

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

@mrkkrp

This comment has been minimized.

Owner

mrkkrp commented Sep 26, 2016

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 mrkkrp added the enhancement label Sep 26, 2016

@mrkkrp

This comment has been minimized.

Owner

mrkkrp commented Sep 26, 2016

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

This comment has been minimized.

Owner

mrkkrp commented Sep 26, 2016

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

This comment has been minimized.

Owner

mrkkrp commented Sep 28, 2016

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

@mrkkrp mrkkrp closed this Sep 28, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment