Skip to content

Labelling/annotating expected items #111

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

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

Labelling/annotating expected items #111

mikeplus64 opened this issue Jun 23, 2016 · 10 comments

Comments

@mikeplus64
Copy link

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
Copy link
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
Copy link
Author

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
Copy link
Author

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
Copy link
Author

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

@mikeplus64
Copy link
Author

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
Copy link
Author

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

@mrkkrp
Copy link
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
Copy link
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
Copy link
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
Copy link
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 as completed Sep 28, 2016
tomjaguarpaw pushed a commit to tomjaguarpaw/megaparsec that referenced this issue Sep 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants