What compromises Scala made to run on JVM?

Question

Scala is a wonderful language, but I wonder how could be improved if it had it's own runtime?
I.e. what design choices were made because of JVM choice?

Frontlet

Answer 1

This article is a discussion with Martin Odersky (Scala's creator) and includes the compromises that were made in Scala for compatibility with Java. The article mentions:

1. Static overloading of methods
2. Having both traits and classes
3. Inclusion of null pointers.

Titoism

Answer 2

The two most important compromises I know about are:

• type erasure ("reflecting on Type"): It has to manage a Manifest to get around the Java compilation (independent of the JVM, for backward compatibility reason).
• collection of primitive type: e.g.: arrays

  new scheme of handling arrays in Scala 2.8. Instead of boxing/unboxing and other compiler magic the scheme relies on implicit conversions and manifests to integrate arrays

Those are the two main JVM limitations, when it comes to manage generic type (with bounds): The Java JVM does not keep the exact type use in a generic object, and it has "primitive" types.

---

But you could also consider:

• Tail-call optimization is not yet full supported by the JVM, was hard to do anyway (and yet Scala 2.8 introduces the @tailrec annotation)
• UAP (universal Access Principle) needs to be emulated (not supported by Java), and will be soon completed for Value Holder (@proxy)
• the all mix-in mechanism needs also to be emulated
• more generally, the huge number of static types introduced by Scala need (for most of them) to be generated in Java:

In order to cover as many possibilities as possible, Scala provides:

• Conventional class types,
• Value class types,
• Nonnullable types,
• Monad types,
• Trait types,
• Singleton object types (procedural modules, utility classes, etc.),
• Compound types,
• Functional types,
• Case classes,
• Path-dependent types,
• Anonymous types,
• Self types,
• Type aliases,
• Generic types,
• Covariant generic types,
• Contravariant generic types,
• Bounded generic types,
• Abstract types,
• Existential types,
• Implicit types,
• Augmented types,
• View bounded types, and
• Structural types which allow a form of duck typing when all else fails

Ludie

Note to self: that list of types is detailled (with links) in #3113225 – Ludie

Answer 3

Less an issue with the runtime than a cultural hangover: universal equality, hashing, toString.

More deeply tied to the VM: strict by default evaluation, impure functions, exceptions.

Cubit

+1 for universal equality and hashing. What's wrong with universal toString? – Mongoose

1) It's easy to accidentally display Object#toString to a user. 2) Collection[A]#toString is inflexible in the way it displays elements of type A. See scalaz.Show for a alternative. – Cubit