When are we getting a lazy compiler?
It would be great to not have to wait for 200 modules to compile when I’m only using 1 of them.
1 Like
I don’t think laziness would help much as long as you’re still compiling at the level of modules or packages. I remember seeing fragnix some time ago. It splits up packages and modules such that each function gets it’s own module and it does not compile more ‘modules’ than it needs.
@jaror I’m unsure of why lazy compilation would be a problem if modules are used. It seems like the module could be split into functions and when called that function could then be compiled. Any function calls in the compiled function could then be lazily compiled.
Yeah, that is exactly what I mean. You have to split modules up into smaller fragments to avoid excessive compilation. I don’t think that this should be called lazy compilation.
Probably query-based compiler as descibed by Olle Fredriksson could help with achieving what you want
Actually, memoization might pay off far more than laziness. That would be “partial precompilation” or even automatic parameterization of each module by the type signatures associated with prior uses of the names it exports.
That memoization and precompilation of different instantiations that might arise in use contexts would likely mean that as a developer works to fix bugs, much of the prior compilation effort can be re-used by lookup, rather than compilation de novo.
Where is the time spent for these 200 module compiles? Probably not in the code generator, I suspect. Probably not in the parser either. Somewhere in between.
But maybe there is a surprise in there, where memoization can pay off?
@looptooner keep it coming. JIT runtime (only for development not deployment), memoization, lazy parser/compiler at the function level