问题
A while ago I read about Scala for LLVM and I kept wondering which things in the Scala language/specification/library) only exist to make the JVM happy or improve interop with Java.
Considering that running Scala on the LLVM provides much more freedoms and the plan is port the language (and not the whole Java ecosystem around it) which features won't make sense there?
Guidance: I'm wondering about things like Object#finalize, the monitor stuff (notify, wait), clone vs. Cloneable, no 64-bit array indices, collection sizes limited to 32-bit, java.lang.String, Java reflection, ...
回答1:
The AnyVal type branch could burn in eternal hell fire. Arrays could be implemented in a sane way (okay, the ugliness is hidden pretty well now), same for reified types. The methods clone, hashCode and toString could go into type classes where they belong. Currying could be implemented without multiple arg lists. Type inference and type level programming could be improved.
回答2:
null, null, null, and null
回答3:
Type erasure. Having every object have a monitor reference (a horrible Java mis-feature).
回答4:
I hope that a Scala port to LLVM include user-defined value types (like struct types in CLR). The issue is avoiding heap allocation. For example, in scientific computing there is a need for abstractions like arrays of complex numbers, but heap allocating each complex number is too costly (in terms of space and cache misses).
Edit: Maybe the JVM will get value types too. John Rose, a JVM engineer, discusses how value types might be added. There are recent rumors that Oracle plans to add value types for better support of high performance computing.
回答5:
Syntax, mostly to not scare away existing java developers.
And entire "let's marry objects with functional programming, because java works only with objects".
Without the need to integrate with existing OO libraries there would be no need to castrate type inference, to make an ugly kludge in form of case classes to support pattern matching.
Heck if you look at it, without JVM there would be no Scala, because most of the compromises simply do not make sense if taken out of context of seamless integration with java world.
来源：https://stackoverflow.com/questions/6256608/which-functionality-feature-in-scala-only-exists-as-a-concession-to-the-underlyi