3 ms·

> No tail calls support Is there a good reason for VMs to support TCO rather than having compilers perform it? > no (optional and confined) unsafe pointer ari

> No tail calls support Is there a good reason for VMs to support TCO rather than having compilers perform it? > no (optional and confined) unsafe pointer arithmetics When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. > no value types Might be added in JVMS 10 or some version thereafter. > a pathetic limit on a method size makes it an extremely shitty target for any language other than Java. True. > All the existing languages running on top of JVM are very, very inefficient, or have to pay a horrible price for being able to run reasonably fast (crap like `recur` in Clojure, for example). Fair enough, but it wasn't designed as a general purpose compilation target like llvm.

sklogic 12y ago
> Is there a good reason for VMs to support TCO rather than having compilers perform it? Again this word! Proper tail calls handling is not an "optimisation". Optimisations are supposed to be optional, while tail calls handling makes a semantic difference. And, no, compilers cannot do it statically. You cannot statically resolve virtual calls, for example. Consider the following trivial case: `(define (f g x) (g x))` > When do you want this? There's sun.misc.Unsafe#setMemory if you really need it. Try implementing, say, an STG efficiently. Or even a WAM. > Might be added in JVMS 10 or some version thereafter. JVM may start to suck less at some point. But now it sucks. > but it wasn't designed as a general purpose compilation target like llvm. Exactly. And that's why it's inferior to the other VMs, which were designed with multiple source language semantics in mind. Including even CLR.