-
Notifications
You must be signed in to change notification settings - Fork 231
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
parse error raised (invalid escape sequence) before string is terminated #1166
Comments
Not exactly what is happening. It is confusing, but here is what is going on:
Now this is confusing but consistent with how other parser errors are handled. |
Shouldn't REPL stop parsing on first parse error? like |
No, since a user at a repl would want to continue after any errors to enter more data. More generally, with some (bad) code snippet like:
(Note the extra close parentheses) - the repl will print both |
I mean, the REPL can print the error, and don't do anything until the user fixed the syntax error. For example, Python
|
Lisp is in general different from Python - Python will read a whole line, parse it, and then evaluate it. If the line is part of a block (ends with some sort of continuation like a Janet is not line based, and does not process your programs in chunks of lines; the parser (reader) goes character by character. When a form is produced, it is compiled and then evaluated. The subsequent forms are not touched.
Perhaps, but also keep in mind the the repl is the same environment as running from a file. The reason the behavior is like this, were there a syntax error, the execution will keep going is to get as much diagnostics information as possible. For example, if there is an error at the beginning of a source file, you would also like to get as many subsequent errors in the output as possible rather than needing to rerun the program one time per error. You can use Ctrl-Q at the repl to cancel the current form though. |
So the confusing part of this is the the error is thrown before the string is completely read, which causes confusing parser state. On a bad string escape, I think more consistent behavior would be to wait until the closing quote is found before raising a parsing error. |
Thanks! this helps |
On parse error, the REPL state is not reset.
terminal trace:
Note the
repl:2:">
. It should berepl:2:>
, without the"
.The text was updated successfully, but these errors were encountered: