Skip to content
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

feat: error recovery, handling and mapping #53

Open
norskeld opened this issue Jan 2, 2023 · 0 comments
Open

feat: error recovery, handling and mapping #53

norskeld opened this issue Jan 2, 2023 · 0 comments
Assignees
Labels
A-combinators Area: Issues related to combinators A-errors Area: Issues related to error handling A-types Area: Issues related to types and type inference C-feature-accepted Category: A feature request that has been accepted and awaiting implementation P-high Priority: High

Comments

@norskeld
Copy link
Owner

norskeld commented Jan 2, 2023

Right now there're no "errors" per se, i.e. all sigma provides users with is text messages and ability to re-map those messages to something custom. This is a shame and should be improved.

Implementation of spans in #34 should help a bit, but we will also need to extend Parser<T> signature with a second generic parameter E, so parsers could bear error type information. All parsers and combinators will be changed accordingly, although I'm pretty sure there'll be hurdles here and there.

Additionally, there should be added two combinators:

  • mapErr(parser, fn) - this combinator will map error from E to some other type using given fn.
  • mapOrElse(parser, okFn, errFn) - this combinator will conditionally apply okFn or errFn depending on the parser's result.

It also makes sense to implement error recovery along with the stuff above. Hopefully, it will be enough to provide a single combinator:

  • recovery(parser, fn) - this combinator takes a parser and a recovery function fn that should produce another parser; similar to when combinator, but it acts only on failures.

Making parsers named (adding name property to Parser<T>) wouldn't hurt as well.

@norskeld norskeld added the feat New feature or request label Jan 2, 2023
@norskeld norskeld self-assigned this Jan 2, 2023
@norskeld norskeld mentioned this issue Jan 2, 2023
@norskeld norskeld changed the title feat: error handling and mapping feat: error recovery, handling and mapping Jan 16, 2023
@norskeld norskeld added A-combinators Area: Issues related to combinators A-types Area: Issues related to types and type inference C-feature-accepted Category: A feature request that has been accepted and awaiting implementation A-errors Area: Issues related to error handling P-high Priority: High and removed feat New feature or request labels Jan 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-combinators Area: Issues related to combinators A-errors Area: Issues related to error handling A-types Area: Issues related to types and type inference C-feature-accepted Category: A feature request that has been accepted and awaiting implementation P-high Priority: High
Projects
None yet
Development

No branches or pull requests

1 participant