Which functionality/feature in Scala only exists as a concession to the underlying platform and should be removed if targeting something else?

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, ...

---

null, null, null, and null

---

Type erasure. Having every object have a monitor reference (a horrible Java mis-feature).

---

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.

---

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.

---

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.