3 ms·

Scala needs to interoperate with other Java languages, and there is no platform-wide spec for supplying such metadata. Even if there were, it couldn't be stati

Scala needs to interoperate with other Java languages, and there is no platform-wide spec for supplying such metadata. Even if there were, it couldn't be statically known at compile time in the case where a library written in Scala is being called by code that was written at a later date. And even without that consideration, types still cannot be statically known in cases where you're being handed objects whose type is not determined until run time. Which happens all the @$#% time in Scala, due to its use of algebraic data types. So, e.g., Java's run-time has no real way of expressing the type `Option<List<String>>`. You can declare it and get some compile-time checking, but that's all erased before the final bytecode is generated. There's no such thing as `Option<List<String>>.class`. This really limits what you can do with generic code. Scala added its own parallel type tag system to get around that. It's weird as heck and only really usable from other Scala code, though.

willtim 9y ago
> Scala needs to interoperate with other Java languages But does it? Can I even use e.g. a Scala collection from Java? (let alone Clojure, Kotlin, etc) Certainly it looks easy to import and use Java objects, but that looks to be the extent of it. > it couldn't be statically known at compile time in the case where a library written in Scala is being called by code that was written at a later date When you build some new code that uses an existing library, any parametric polymorphic type variables get instantiated at the use sites. Where I admit this isn't true, is the adhoc polymorphic dynamic dispatch via subtyping, but this wasn't given to me as an example. I don't see that ArrayLists and ADTs should present a problem. > types still cannot be statically known in cases where you're being handed objects whose type is not determined until run time Again, I think you are referring to dynamic dispatch here? I agree this could be a problem in open class hierarchies. But the ADT encoding in Scala is a closed statically-known hierarchy, so I can't see why it has to cause problems. Truly "generic" or parametric polymorphic code should not depend on type tags or even be allowed to introspect the runtime type, doing so violates parametricity, which ultimately reduces our ability to reason about the code.
- bunderbunder 9y ago
  > Can I even use e.g. a Scala collection from Java? (let alone Clojure, Kotlin, etc) Yup to all. Sometimes the code comes out looking a bit ugly (e.g, you can access default parameters from Java, but it's done by calling methods with kind of awful auto-generated names), but the only things you really can't get at are things that relies on implicits, type tags, or traits with fields.

willtim 9y ago

> Scala needs to interoperate with other Java languages But does it? Can I even use e.g. a Scala collection from Java? (let alone Clojure, Kotlin, etc) Certainly it looks easy to import and use Java objects, but that looks to be the extent of it. > it couldn't be statically known at compile time in the case where a library written in Scala is being called by code that was written at a later date When you build some new code that uses an existing library, any parametric polymorphic type variables get instantiated at the use sites. Where I admit this isn't true, is the adhoc polymorphic dynamic dispatch via subtyping, but this wasn't given to me as an example. I don't see that ArrayLists and ADTs should present a problem. > types still cannot be statically known in cases where you're being handed objects whose type is not determined until run time Again, I think you are referring to dynamic dispatch here? I agree this could be a problem in open class hierarchies. But the ADT encoding in Scala is a closed statically-known hierarchy, so I can't see why it has to cause problems. Truly "generic" or parametric polymorphic code should not depend on type tags or even be allowed to introspect the runtime type, doing so violates parametricity, which ultimately reduces our ability to reason about the code.

bunderbunder 9y ago
> Can I even use e.g. a Scala collection from Java? (let alone Clojure, Kotlin, etc) Yup to all. Sometimes the code comes out looking a bit ugly (e.g, you can access default parameters from Java, but it's done by calling methods with kind of awful auto-generated names), but the only things you really can't get at are things that relies on implicits, type tags, or traits with fields.