Hacker News Reader

Comment by vlovich123 | Hacker News Reader

The combinatorial explosion is intractable but since it only seems to come up in really obscure corner cases, I wonder if the typical inference scenarios can be solved by having the compiler cache the AST across invocations so that inference only needs to be performed on invalidated parts of the AST as it’s being typed instead of waiting for the user to invoke the compiler.

View on HN

I think the challenge here is that it only happens for a type error, not a successful compilation. Each time this happens, the programmer would try to fix the type error, usually invalidating the cache.

I'm not so sure the problem is intractable because it's so well-structured. Someone would have to look at it and check that there aren't any low-hanging fruits. The challenge might be that anyone who could fix this could make much more impactful contributions to the compiler. But it's hard to know without trying.

I still have a hunch that editors, when attempting to assist the developer, should have memory of the last clean copy of the code and use that for inference, as much or moreso than the current code.

In particular there are no guarantees that as I am writing a new method that I have the brackets balanced to make the code around it be seen as valid code. I'm so tired of not being able to use autocomplete in the middle of a complex edit unless I ritualistically write the code in an order that is unnatural to me.

Similarly, if I'm iteratively trying to fix a type error, the previous edit was not sane, and is of no help at all. You may have to go several edits back.

I think it would also be interesting for the compiler to modify the source code (with a flag, presumably, or possibly through the local LSP server) with the solved result as needed. This would also feedback to the programmer what the problem is, what the compiler thought the solution is (and under the circumstances, while it can't be "wrong" there's a decent chance it is suboptimal or not what the programmer expected), and not require future caching.

I kind of feel like that for more advanced languages this sort of back-and-forth between the type checker and the language has some potential to it.

Why not make it a warning if the compiler leaves the happy path? The fix is easy for the programmer (enums, casting, etc.) and could be left unfixed if the programmer knows its OK (meaning it wont take 42 seconds and give an error.) The LSP would have to know when the compiler ran into this, but if the compiler can identify the type explosion problem, it can tell the LSP.

I don't think it comes up in obscure corner cases now with SwiftUI's builder types being concrete, especially with overloaded callbacks like in ForEach

Edit: I just remembered my favorite one: I had a view where the compile times doubled with every alert I added to it.

Reply on news.ycombinator.com