4 ms·

One problem is that the JVM is specifically designed to be the backend for Java (and an outdated version of Java at that). It has a number of assumptions hardc

One problem is that the JVM is specifically designed to be the backend for Java (and an outdated version of Java at that). It has a number of assumptions hardcoded into its design, making it difficult to use it as a target architecture for programming languages that have different requirements. You run into problems currently if you need structs, complex numbers, unusal parameter-passing conventions (call by reference, call by name, call by value-result), currying, tail calls, multiple dispatch, multiple inheritance, structural subtyping, algebraic datatypes, continuations, fast thread-local variables, micro-threads, coroutines, ICON/Python/C#/Sather-style generators, nested functions, software transactional memory, etc. It is not that you cannot have these features (after all, the JVM is Turing-complete, and quite a few JVM languages do support them), it's that at some point using the JVM loses its advantages over, say, targeting the LLVM or CLR. On top of that you have JVM-specific downsides to deal with (such as a fairly large memory footprint even for small processes).

soc88 15y ago
Most of it is supported in Scala, without much problems.
- rbehrends 15y ago
  Scala's compiler has to jump through quite a few hoops to get it done (e.g., trampolines for some forms of tail recursion). It also can't fix the overhead issues involved with, say, complex numbers (which may or may not get fixed in the future [1]). Try to do a simple Gaussian elimination on a 1000x1000 matrix of complex numbers, for example. The indirections and per-object overhead are bad for your processor cache. [1] https://blogs.oracle.com/jrose/entry/value_types_in_the_vm https://blogs.oracle.com/jrose/entry/value_types_in_the_vm
  - soc88 15y ago
    That's why I said: > Most of it is supported in Scala scalac does not use trampolining. It rewrites tail-recurisve calls into “loops” (or jumps if you look at the bytecode). This is a case where the JVM lacks the necessary feature. There are experiments with value classes in Scala, which might allow you to use arrays of primitive numbers for them, but currently it looks like it won't happen for 2.10 because it can't be made work good enough in some corner cases like reflection, toString, equality, ...
    - rbehrends 15y ago
      No, Scala cannot optimize all forms of tail recursion (such as mutually tail-recursive functions). In that case, you have to use scala.util.control.TailCalls to do it via trampolines. The proposed value classes in Scala do not solve the overhead problem for complex numbers. As specified in SIP-15, they have exactly one field, and basically are designed to give you information hiding for classes with a single field without boxing overhead. Edit: By the way, you don't have to sell me on Scala. I have been using it since 1.x (I have forgotten the exact version number).
      - soc88 15y ago
        Sorry, if I appeared as I tried to sell you something. > No, Scala cannot optimize all forms of tail recursion (such as mutually tail-recursive functions). In that case, you have to use scala.util.control.TailCalls to do it via trampolines. I guess we are just nick-picking each other here. :-) I think be both understand what the compiler can do, cannot do, what it does automatically and what not. Have you seen the Complex implementation which uses an underlying Long as Floats? (Sounds ugly but seems to work quite nicely.) The biggest problem at the moment is putting value types in an array. Currently it seems like some ugly clutch/work-around ill be used. I hope SIP-15 gets either rejected or delayed until there is a better solution, Because the difference between an array of references and an array of primitives really matters imho.

soc88 15y ago

Most of it is supported in Scala, without much problems.

rbehrends 15y ago
Scala's compiler has to jump through quite a few hoops to get it done (e.g., trampolines for some forms of tail recursion). It also can't fix the overhead issues involved with, say, complex numbers (which may or may not get fixed in the future [1]). Try to do a simple Gaussian elimination on a 1000x1000 matrix of complex numbers, for example. The indirections and per-object overhead are bad for your processor cache. [1] https://blogs.oracle.com/jrose/entry/value_types_in_the_vm https://blogs.oracle.com/jrose/entry/value_types_in_the_vm
- soc88 15y ago
  That's why I said: > Most of it is supported in Scala scalac does not use trampolining. It rewrites tail-recurisve calls into “loops” (or jumps if you look at the bytecode). This is a case where the JVM lacks the necessary feature. There are experiments with value classes in Scala, which might allow you to use arrays of primitive numbers for them, but currently it looks like it won't happen for 2.10 because it can't be made work good enough in some corner cases like reflection, toString, equality, ...
  - rbehrends 15y ago
    No, Scala cannot optimize all forms of tail recursion (such as mutually tail-recursive functions). In that case, you have to use scala.util.control.TailCalls to do it via trampolines. The proposed value classes in Scala do not solve the overhead problem for complex numbers. As specified in SIP-15, they have exactly one field, and basically are designed to give you information hiding for classes with a single field without boxing overhead. Edit: By the way, you don't have to sell me on Scala. I have been using it since 1.x (I have forgotten the exact version number).
    - soc88 15y ago
      Sorry, if I appeared as I tried to sell you something. > No, Scala cannot optimize all forms of tail recursion (such as mutually tail-recursive functions). In that case, you have to use scala.util.control.TailCalls to do it via trampolines. I guess we are just nick-picking each other here. :-) I think be both understand what the compiler can do, cannot do, what it does automatically and what not. Have you seen the Complex implementation which uses an underlying Long as Floats? (Sounds ugly but seems to work quite nicely.) The biggest problem at the moment is putting value types in an array. Currently it seems like some ugly clutch/work-around ill be used. I hope SIP-15 gets either rejected or delayed until there is a better solution, Because the difference between an array of references and an array of primitives really matters imho.