Conversation

There are a couple of reasons for doing this! It makes editors less privileged than other tools that may want to inspect/interact with the proof assistant. It also means that it's easier to write complex refactoring tools without extreme levels of pain
1
1
This does make implementation somewhat more tricky, but I think we can design libraries that can do a lot of the heavy lifting for you
1
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Exactly. However, rust-analyzer still has to go through LSP. I'm saying we chuck that step out entirely and expose the query language /as the protocol/
2
2
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
I think he still contends that the Dart editor protocol is a better design, but they use the LSP out of necessity. Been trying to get him interested in typed holes but yeah, I'm not very good at selling this stuff other than ‘try Adga/Idris’ or ‘it's cool!’.
2
2
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
You’re unable to view this Tweet because this account owner limits who can view their Tweets. Learn more
Maybe pointing to how people use `()` and `_` in types already, and `todo!()` could help, but I dunno. I think maklad would say something like ‘let's just use those’, but it ends up being disjointed and not-so-nice compared to a more integrated solution like in Agda.
1
2
Granted Rust's types are much weaker right now re. effects, so you'd end up getting less value out of them, but I still am pretty sure you'd get a decent amount of value out of them (potentially more so with the context/effect stuff on the horizon).
1
1
Show replies