Composing Parsers with different Error types

[Swiftb0y]

I'm currently prototyping a parser and gradually trying to improve their error reporting and types. I can't really find a way to adapt from a parser of one error type (for example EmptyErr) to a parser of another error type (such as Rich<_>). Parser::map_err only allows me to change the content (since the functor is of type Fn(E::Error) -> E::Error). State and Context do have mapping functions (such as map_ctx or with_ctx, with_state) but I as far as I can tell there is no equivalent for an Error?

[zesterer]

There is currently no way to do this, sadly. Unlike state and context, error tracking is non-trivial and there's not an easily composable way to move between error types during a parse.

Is there a particular use-case you have in mind?

[Swiftb0y]

Is there a particular use-case you have in mind?

Well in this case I just want to be able to refactor gradually. Rather than switching the signatures of all parser functions at once, it would be nicer if I could start slowly from the inside out or outside in. When moving from a more meaningful error type to a less meaningfull, the information attached to the error could just be thrown away, vice versa the more meaningful error could be generated from the inputref. It seems I'm underestimating the complexity here. Does that suffice as a usecase description or would you like some code to illustrate it?

[zesterer]

I think there's more complexity here than you might realise. Chumsky isn't just a wrapper over a set of functions that return Result<O, E::Error>. During parsing, we carry state about the current set of 'potential-errors' around with the parser, embellishing it as the parse tree gets explored. We can't easily just drop that state.

It is usually a good idea to use a type/trait alias to define your error type in a single place, then you can reference it in many other places. I'd recommend starting off by using your current error type in this alias, swapping all uses, checking that it compiles, and then proceeding with the refactor.

[Swiftb0y]

Yeah, thats probably gonna be the way to go. Thanks for your tips and time.

[zesterer]

Good luck!