4 ms·
> It's not just about the compiler being smart. There is nothing more you can do with x -> 2 + x other than compile it as is. > It is also about the language p
by wfunction 9y ago
> It's not just about the compiler being smart. There is nothing more you can do with x -> 2 + x other than compile it as is.
> It is also about the language providing you the tools to express certain invariants that the compiler can use.
Compiled code is useless if it is never called. The moment it's called, whether the caller is known during compilation or not, the caller can pass down any additional information it has, whether for that call or to help the callee optimize future calls. Heck, if it really wants to, the compiler could simply let the "compiled" code be the AST or source code itself (plus a JITter), and make the program generate code on the fly when the caller calls it, optimized using whatever information the caller is willing to provide. Again, nothing fundamentally in a language preventing this. It a tradeoff between implementation difficulty, execution latency, program size, and the like.
- dkarapetyan 9y agoThat language with your described properties already exists and is called SBCL (http://www.sbcl.org/ http://www.sbcl.org/). I'm not sure what you're arguing at this point though and don't quite get what point you're making. Compilers, optimizations, type systems, and proof systems are all very closely related and if you want correct optimizations then you must annotate your code with types that the compiler can verify and use as assumptions in an optimization pipeline. These things are not easy to engineer. Saying just JIT it doesn't make much sense.
- kybernetikos 9y agoBut doing the optimization at runtime will slow down at least one run (and probably more) compared to doing the optimization at compile time.