feat: error recovery, handling and mapping #53
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
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 parameterE
, 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 fromE
to some other type using givenfn
.mapOrElse(parser, okFn, errFn)
- this combinator will conditionally applyokFn
orerrFn
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 aparser
and a recovery functionfn
that should produce another parser; similar towhen
combinator, but it acts only on failures.Making parsers named (adding
name
property toParser<T>
) wouldn't hurt as well.The text was updated successfully, but these errors were encountered: