6 comments

[ 5.6 ms ] story [ 25.5 ms ] thread
Fascinating. Is this a separate thing that would be integrated into an IDE or would it make more sense as part of the compiler? Are there any plans to productize this for any language? Any plans to provide a semantic feedback mechanism so that language-specific semantics can be fed back to make the suggestions even better (beyond just the structure of code)?
> Is this a separate thing that would be integrated into an IDE or would it make more sense as part of the compiler?

As things stand it's most easily used in a batch setting (e.g. a compiler). I don't think it would take much, if any, work to use in an incremental parsing (for an IDE), but I haven't tried that yet!

I’d be interested in helping you integrate that into an IDE if you’re open to it.
I'm not an IDE person myself (I'm a neovim person), but I'd love to see someone integrate such an approach into an IDE! The algorithm is free available and the implementation in Rust (grmtools) the same. If you wanted to reuse the Rust code, and it needs some tweaks, then I'm sure that we can find a way to support both batch and IDE-ish use cases well.
I'd much rather have a helpful compiler error than run something that has been "repaired" and may silently do the wrong thing.
You wouldn't be running anything that has been repaired, the fact that a repair is done means that a syntax error has occurred and compilation has failed. The repair is just a recovery strategy so that the compiler can work further in order to potentially uncover further errors.

This is what compilers do already, one such strategy is to unwind the state to before the error and skip over the erroneous part. This can be a bit problematic in certain situations, such as a syntax error in a variable definition and the following flood of 'undefined variable' errors.

The repair strategy in the article is trying to optimise the quality of the attempted repair in order to provide better error messages to the user.