3 ms·

Haskell has shown that you can have erased generics and have reified generics opt-in (i.e. Typeable and Generic). Works perfectly. And the vast majority of gen

Haskell has shown that you can have erased generics and have reified generics opt-in (i.e. Typeable and Generic). Works perfectly. And the vast majority of generic Haskell code does not have either of those constraints, which makes you think how important reified generics as-default really is.

masklinn 8y ago
> Haskell has shown that you can have erased generics and have reified generics opt-in (i.e. Typeable and Generic). Works perfectly. Haskell has little to no RTTI, which makes erased generic a non-issue. Java/C#/Dart have a lot of RTTI, which makes erased generics problematic. Without RTTI/reflection capabilities, generics reification become a performance tradeoff, with it they become a logic/correctness issue.
- int_19h 8y ago
  It's not just RTTI. There are some idioms in OOP languages that legitimately ought to apply to generics, but don't if you erase. For a fairly common example, a class implementing several specializations of the same generic interface. Suppose we have Convertible<T> for something that can make a T out of itself - it would be perfectly reasonable for an object to be both Convertible<int> and Convertible<string>, but you can't do that in Java. And this doesn't require RTTI checks at call site at all - it might be that the caller is itself generic, and is just trying to accept something that's Convertible<U> for its own U.
  - bunderbunder 8y ago
    It also happens with method overloading. In Java, you can't have a class that has both of these methods at the same time: Integer sum(List<Integer> values) { ... } float sum(List<Float> values) { ... } because, as far as Java is concerned, both of these methods have exactly the same argument list. You also have no way in the language to express things like "Map<String, Option<Integer>>.class", which has some ergonomic implementations. (e.g., see: http://gafter.blogspot.com/2006/12/super-type-tokens.html http://gafter.blogspot.com/2006/12/super-type-tokens.html) The gotcha here, though, is that Haskell doesn't have these problems, or the one with implementing multiple specializations of the same generic type, even though it erases types much more completely than Java does. I'm not much of an expert on language design, but that leaves me thinking that there's probably a lot of stuff we lay at the feet of Java's type erasure that is actually more properly attributable to having a type system that is broken in some fundamental way. Or maybe it's the way that type erasure interacts with dynamic dispatch in an object-oriented language? Since the dynamic dispatch means that there are decisions about datatypes that a language like Haskell or ML can sort out at compile time, but that an OO language like Java must delay until run-time?
    - int_19h 8y ago
      In this case I suspect Haskell just passes the appropriate "view" of the value, since it knows what the target type class is at any given point, and - most importantly - it can't be "downcast" later through that same value; you can't do a runtime check for whether a given Convertible<T> is also Convertible<U> (either explicitly, or observable via dynamic dispatch). In Java, it's possible, so even if the code never actually does that anywhere, it always has to be pessimistic and assume that someone somewhere might. But I'm not sure that truly counts as type erasure. If that's how things are done, then the type class of every such value is effectively encoded by the set of function values that are passed around, and could be queried at runtime - the Java equivalent would be to tag every reference with its class, including all generic parameters used to instantiate it.
  - masklinn 8y ago
    You can do that in Haskell so it's not a problem of type erasure (last time I checked, GHC type-erases generics by default). It's a problem more specific to Java's generics implementation.
    - whateveracct 8y ago
      Java reflection is what’s broken not its generics. It does generics correctly by erasing - that’s the proven state-of-the-art :)
- whateveracct 8y ago
  Typeable and Generic are “RTTI”.

masklinn 8y ago

> Haskell has shown that you can have erased generics and have reified generics opt-in (i.e. Typeable and Generic). Works perfectly. Haskell has little to no RTTI, which makes erased generic a non-issue. Java/C#/Dart have a lot of RTTI, which makes erased generics problematic. Without RTTI/reflection capabilities, generics reification become a performance tradeoff, with it they become a logic/correctness issue.

int_19h 8y ago
It's not just RTTI. There are some idioms in OOP languages that legitimately ought to apply to generics, but don't if you erase. For a fairly common example, a class implementing several specializations of the same generic interface. Suppose we have Convertible<T> for something that can make a T out of itself - it would be perfectly reasonable for an object to be both Convertible<int> and Convertible<string>, but you can't do that in Java. And this doesn't require RTTI checks at call site at all - it might be that the caller is itself generic, and is just trying to accept something that's Convertible<U> for its own U.
- bunderbunder 8y ago
  It also happens with method overloading. In Java, you can't have a class that has both of these methods at the same time: Integer sum(List<Integer> values) { ... } float sum(List<Float> values) { ... } because, as far as Java is concerned, both of these methods have exactly the same argument list. You also have no way in the language to express things like "Map<String, Option<Integer>>.class", which has some ergonomic implementations. (e.g., see: http://gafter.blogspot.com/2006/12/super-type-tokens.html http://gafter.blogspot.com/2006/12/super-type-tokens.html) The gotcha here, though, is that Haskell doesn't have these problems, or the one with implementing multiple specializations of the same generic type, even though it erases types much more completely than Java does. I'm not much of an expert on language design, but that leaves me thinking that there's probably a lot of stuff we lay at the feet of Java's type erasure that is actually more properly attributable to having a type system that is broken in some fundamental way. Or maybe it's the way that type erasure interacts with dynamic dispatch in an object-oriented language? Since the dynamic dispatch means that there are decisions about datatypes that a language like Haskell or ML can sort out at compile time, but that an OO language like Java must delay until run-time?
  - int_19h 8y ago
    In this case I suspect Haskell just passes the appropriate "view" of the value, since it knows what the target type class is at any given point, and - most importantly - it can't be "downcast" later through that same value; you can't do a runtime check for whether a given Convertible<T> is also Convertible<U> (either explicitly, or observable via dynamic dispatch). In Java, it's possible, so even if the code never actually does that anywhere, it always has to be pessimistic and assume that someone somewhere might. But I'm not sure that truly counts as type erasure. If that's how things are done, then the type class of every such value is effectively encoded by the set of function values that are passed around, and could be queried at runtime - the Java equivalent would be to tag every reference with its class, including all generic parameters used to instantiate it.
- masklinn 8y ago
  You can do that in Haskell so it's not a problem of type erasure (last time I checked, GHC type-erases generics by default). It's a problem more specific to Java's generics implementation.
  - whateveracct 8y ago
    Java reflection is what’s broken not its generics. It does generics correctly by erasing - that’s the proven state-of-the-art :)
whateveracct 8y ago
Typeable and Generic are “RTTI”.