It's very helpful to see the big picture of pull vs push-pull and caching; often capabilities just get tacked on as needed, to eventually build a mess. Before

It's very helpful to see the big picture of pull vs push-pull and caching; often capabilities just get tacked on as needed, to eventually build a mess. Before LSP, an earlier generation of java compilers circa 2001 (eclipse, then javac) supported incremental compilation and model queries. This effort extended into runtime hot-reload of compatible code (which was ambitious, but has mostly been limited to changing function bodies). Here's a reddit post with a nice video on point with an excellent series of references (the author may have seen, but they didn't post references to what they read): https://www.reddit.com/r/ProgrammingLanguages/comments/ge0s34/comment/fplmldc/ https://www.reddit.com/r/ProgrammingLanguages/comments/ge0s3... The database framing and input caching you mention suggests a new compiler might benefit from using a database instead of in-memory trees and such. In particular, I wonder if datalog style database, with declared code as rules with type consequences, would help. (i.e., the general type rules stay, while declared instances show as new relations with consequence per the general rules). Often those datalog systems built via relation models (A -> B via R) have an extra revision field, and update just by issuing new revisions (i.e., without actually deleting the old), resulting in systems where you can backtrack in time (and don't pay for deletions/memory managment until needed). Such revision history might be helpful for calculating proposed fixes (by unwinding to a last-known-good state, and then changing subsequent edit-declarations/operations). However, all such databases I'm familiar now with force you to copy data to get results, and few have robust query caching or planning or extensible query functions. It would be interesting if someone purpose-built a relation and rules database for compilers.