Skip to content
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

Support informative error-tolerant parsing #294

Open
Trivaxy opened this issue Sep 23, 2023 · 0 comments
Open

Support informative error-tolerant parsing #294

Trivaxy opened this issue Sep 23, 2023 · 0 comments

Comments

@Trivaxy
Copy link

Trivaxy commented Sep 23, 2023

Mecha's parser will raise an exception and halt parsing the given input when it encounters a syntax error. Although this behavior is sensible, it'll be prohibitive when efforts are made to make Mecha act as an LSP, and furthermore, returning a list of errors to any person using this library is more helpful than raising an exception and stopping.

As it is now, when Mecha encounters an error, an exception is raised which propagates upwards and terminates the entire process. Some work has to be done to make the parser:

  • Error tolerant: When encountering a syntax error, the parser should be able to recover. The first and easiest option is to discard parsing the entire line when an error is found, but this means that the rest of the line will not be parsed for information that can discover further errors or aid the LSP.
    The second option is to discard the current node that is being parsed and skip tokens until the boundary of the next node is reached. This is more granular and informative than skipping lines but requires a little more work (for example, when parsing an erroneous node such as ~ # ~, would the entire node be skipped, or only the middle coordinate part?).
    Furthermore, we need a good heuristic for what constitutes a node boundary. In other words, when recovering from an error, when do we stop skipping tokens to try to parse a node? Attempting to resume parsing in the middle of another piece of malformed text will only yield more errors and this can cascade to very poor error recovery.

  • Error information: This one is simpler - we just need every error to include what exactly went wrong, as well as where it occurred in the source. An LSP would use this information highlight errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant