3 ms·
Just to make the MVP simpler. I note in the caveats that the current approach is to recompute everything whenever even one file is changed. But that’s probably
by azdavis 4y ago
Just to make the MVP simpler.
I note in the caveats that the current approach is to recompute everything whenever even one file is changed. But that’s probably not sustainable, as I admit myself in https://azdavis.net/posts/pl-idea-tooling/ https://azdavis.net/posts/pl-idea-tooling/ :
> As an example, it would be unsustainable if, every time we changed a single function’s body, the language server had to re-typecheck the entire codebase. This might work for an initial proof-of-concept on a small codebase, but for large ones, the responsiveness of the language server would drop precipitously.
If I get around to addressing this, I’d probably use salsa and/or follow along this post: https://rust-analyzer.github.io//blog/2020/07/20/three-architectures-for-responsive-ide.html https://rust-analyzer.github.io//blog/2020/07/20/three-archi...
- epage 4y agoSounds like they are making salsa easier to adopt https://smallcultfollowing.com/babysteps/blog/2022/08/18/come-contribute-to-salsa-2022/ https://smallcultfollowing.com/babysteps/blog/2022/08/18/com...
- mananaysiempre 4y ago>> As an example, it would be unsustainable if, every time we changed a single function’s body, the language server had to re-typecheck the entire codebase. If only there were a type system[1] where you could reinfer the function’s type in isolation and then recheck all uses! (I don’t think Trevor Jim’s work on System P2 and System P received any further development, even in “better SML” work like 1ML, which seems like a shame, so I’m going to shill it wherever it appears relevant.) [1] https://dl.acm.org/doi/10.1145/237721.237728 https://dl.acm.org/doi/10.1145/237721.237728