REPL "hangs" on every parser error, even when it shouldn't

[porcuquine]

Internally, u64s wrap as expected. However, too-large input hangs. I expect either an error (probably) or the wrapping behavior (probably not).

commit: 2024-11-15 322297f014d9d2c2b6e26c4f164e354d73277ba8
Lurk REPL welcomes you.
lurk-user> (+ 1 18446744073709551615)
[3 iterations] => 0
lurk-user> (+ 2 18446744073709551615)
[3 iterations] => 1
lurk-user> 18446744073709551616

[wwared]

What happens here is that there is a parser error, so it's treated the same as a missing ) and keeps waiting for further input, since right now the REPL treats all parse errors the same way. You can view the error by pressing enter multiple times which forces the REPL to print the error to the console. The precise error is "Error: Parsing Error: ParseError { input: LocatedSpan { offset: 0, line: 1, fragment: "18446744073709551616\n\n", extra: () }, expected: None, errors: [Nom(Tag), Nom(Tag), Nom(Char), Nom(Tag), Nom(Tag), Nom(Char), Nom(Char), Nom(Alt), Nom(NoneOf), Nom(Alt), Nom(Tag), Nom(Tag), ParseIntErr(ParseIntError { kind: PosOverflow }), Nom(Tag), Nom(Tag), Nom(Alt)] }". It's a nasty error struct but basically it means all the parsers it tried executing have failed (see the ParseIntErr(ParseIntError { kind: PosOverflow }) part).

In my opinion, the better solution here is for reader errors to be separated into "soft errors" like unclosed delimiters, which cause the REPL to keep reading input despite the error (since the user might close the delimiter still), and "hard errors" like this where the reader immediately returns the error, since the user needs to go back and edit things to fix the error.

[wwared]

Renaming this issue to track the fact that the parser errors should be differentiated between "unrecoverable" errors that should be immediately reported, and "recoverable" errors that indicate missing input, and the REPL should differentiate between those two types of errors