Defer error in string

[jamesdbrock]

string is potentially slow on failure because of the show call to the input string. Failure cases are hit very often, and if you are using string a lot this can be significant overhead. Deferred errors might be better in general.

Originally posted by @natefaubion in #144 (comment)

[jamesdbrock]

This is a benchmark for failing a string parser 10,000 times. The second measurement is for a string parser modified so that it fails with a constant string error message.

Current situation	Constant error string
runParser manyTill anyChar (string "x") 10000 mean = 8.12 ms stddev = 736.03 μs min = 7.52 ms max = 12.80 ms	runParser manyTill anyChar (string "x") 10000 mean = 6.11 ms stddev = 794.22 μs min = 5.49 ms max = 11.16 ms

[jamesdbrock]

I think that deferring error message construction in the case of manyTill anyChar (string "x") would require us the change the type of

purescript-parsing/src/Parsing.purs

Line 39 in cade0cd

data ParseError = ParseError String Position

to

 data ParseError = ParseError (Unit -> String) Position 

?

[jamesdbrock]

Also I think we don't even want the error functions to prepend "Expected " to everything, and we should remove that anyway.

purescript-parsing/src/Parsing/Combinators.purs

Line 105 in c160c90

withErrorMessage p msg = p <|> fail ("Expected " <> msg)

[jamesdbrock]

And while we're at it should we accumulate a NonEmptyList of ParseErrors?

[chtenb]

In what situation would there be more than 1 parser error? Or do you want to track all the backtracking decisions in that error list?

[natefaubion]

It's not clear to me there is value in having multiple errors with the current approach to error handling and recovery (or lack thereof). The point of the current "consumed" check is that it's a heuristic for generating a single, specific error. If you wanted to have multiple errors, you would want to remove the check, always backtrack, and then let the user decide which is most specific (potentially by how far it progressed). I personally don't think it's worth doing in this library without having a clear idea of what you wanted to accomplish and enable that is better than the status quo.

[natefaubion]

Note, a "deferred" error doesn't necessarily need to be a thunk. It could potentially just be a structured data type that is constant-time to construct, and potentially only applies escaping rules when rendered.

[jamesdbrock]

In what situation would there be more than 1 parser error?

It's not clear to me there is value in having multiple errors

Yeah, let's not do multiple errors.

Note, a "deferred" error doesn't necessarily need to be a thunk. It could potentially just be a structured data type that is constant-time to construct, and potentially only applies escaping rules when rendered.

What would that look like?

[natefaubion]

Maybe something like:

data ParseError
  = UnexpectedInput { inputExpected :: Array String, inputSeen :: String }
  | ...
  | EmptyAlternative

I'm not sure what other data types would be there, but you might look at what kind of errors we throw and see if it makes sense for others to throw them. The most common is invariably unexpected input errors.