Guidance on how to achieve some level of error recovery

[chrisspre]

Is there any tips or guidance how to achieve some sort of error recovery for a superpower parser so that the parser can report multiple, independent syntactical errors?

Without extra caution a superpower parser stops parsing when it discovers an error which means an end-user needs to fix one error at a time.
Typically programming languages show multiple errors in one file. My understanding is that these parsers detect one error per "statement" (a common production rule) and skip over some text until the next statement is discover.
How can this be achieved in superpower?

[nblumhardt]

Hi @chrisspre - unfortunately, no, this is unexplored territory for Superpower. It would be extremely interesting to hear what you come up with, if you decide to dig in further. My guess is that some of Superpower (as it stands today) could be reused, but there would need to be fairly deep changes to support recovery/reporting of multiple errors.

Best regards,
Nick

[nblumhardt]

We're trialling GitHub Discussions in some of the Datalust repositories. This thread seems like a good candidate for a discussion, I hope you don't mind me converting it, @chrisspre - let me know if you had any trouble locating it/navigating across here to the new location 👍

[nblumhardt]

Odd - I received your reply by email, but can't see it here. I can see discussions even when not logged in, however.

In case it helps, the URL is #124

[chrisspre]

I had no response yet. Was only looking around, trying to find GitHub Discussions only to realized this is where we are :-)

For what it's worth, here is an early thought:
I think the result type would need to change. Instead of it being either a Value or an Error, I think it would need to become a Value and a list of errors.

Something like

interface IResult<T>
{
   T Value { get; }
   IImmutableList<Error> Errors { get; }
}

I believe there is still a monadic join operator on this that allows to compute values from previous ones, that also always accumulates errors. Other combinators should be possible to derive from this.
I will try to prototype this and report back.

[chrisspre]

The list of errors is not sufficient, there still needs to be a way to distinguish between Success and Failure. But having the list of errors would allow to write a combinator that turns a Failure into a Success by adding the error to the list and consuming a number of tokens up to a place where parsing can "resume"

[xtofs]

just stumbled upon https://keleshev.com/advanced-error-handling-in-ocaml
Quote:
The result type can express either a success result on an error (or a list of errors, in our case). To express a result obtained after recovering from an error, we need to change the result type from a variant type to a sum type.
Quote 2:
_What we have implemented can be described as a composition of an option monad and a writer monad. _