3 ms·

To be fair, there's absolutely nothing wrong with type erasure, except when you allow runtime reflection. If there is no reflection, then it shouldn't be possi

To be fair, there's absolutely nothing wrong with type erasure, except when you allow runtime reflection. If there is no reflection, then it shouldn't be possible to observe whether or not type erasure is done.

olliej 10y ago
It really depends at what level -- because the erasure is done at the language level rather than the VM you _have_ to have a pile of runtime casts, even when those casts are no-ops :-/ I agree it works, i just don't think it's as elegant :D Of course eventually everything is running on an untyped CPU and everything is just an integer so it's all erased in the end. Unless you have one of those silly mid-90s java cpus right? Or maybe a LISP-machine
- pjmlp 10y ago
  > silly mid-90s java cpus They are still quite actual, here is one example. http://www.imsystech.com/products/im3910-ic/ http://www.imsystech.com/products/im3910-ic/
- wtetzner 10y ago
  Well, that's a detail of how the VM works. My only point was that type erasure is not inherently bad, as plenty of languages do type erasure, like Haskell and OCaml. Of course you can always create conditions where it could become a problem. But the example with C# "doing it right" is a little odd in that case, since Microsoft had the opportunity to build something new, that didn't have the same issues the JVM had. And they did, in some ways, but that doesn't mean tracking type parameters at the VM level is the only way to do it "right".
danarmak 10y ago
Even without full-blown reflection, the problem is that you don't have an "is instance of" operation for unerased types. Which is crucial to case/match as used in Scala and functional programming in general.
- wtetzner 10y ago
  It is not crucial for functional programming, unless your functional programming language uses types as variant tags. Both Haskell and OCaml use type erasure, and I doubt anyone would claim they aren't functional languages.
  - danarmak 10y ago
    If they store a variant tag, that means they don't erase the bit of info that's needed for case matching. My point is that it's crucial to be able to tell at runtime to which (sub)type a value belongs. Other type information that isn't necessary for that can still be erased.
    - wtetzner 10y ago
      I think we're in agreement, and just tripping over terminology. In most functional languages, values in a variant are just values in that variant. They don't each have their own type, which means the variant tag isn't actually type information.
zigzigzag 10y ago
You can observe it on the JVM when you realise you can't overload a function with arguments that differ only in generic type.
- wtetzner 10y ago
  Yes, my point was that there's nothing inherently wrong with type erasure. You can of course create conditions that would be problematic, like the design of Java and JVM does.

olliej 10y ago

It really depends at what level -- because the erasure is done at the language level rather than the VM you _have_ to have a pile of runtime casts, even when those casts are no-ops :-/ I agree it works, i just don't think it's as elegant :D Of course eventually everything is running on an untyped CPU and everything is just an integer so it's all erased in the end. Unless you have one of those silly mid-90s java cpus right? Or maybe a LISP-machine

pjmlp 10y ago
> silly mid-90s java cpus They are still quite actual, here is one example. http://www.imsystech.com/products/im3910-ic/ http://www.imsystech.com/products/im3910-ic/
wtetzner 10y ago
Well, that's a detail of how the VM works. My only point was that type erasure is not inherently bad, as plenty of languages do type erasure, like Haskell and OCaml. Of course you can always create conditions where it could become a problem. But the example with C# "doing it right" is a little odd in that case, since Microsoft had the opportunity to build something new, that didn't have the same issues the JVM had. And they did, in some ways, but that doesn't mean tracking type parameters at the VM level is the only way to do it "right".

danarmak 10y ago

Even without full-blown reflection, the problem is that you don't have an "is instance of" operation for unerased types. Which is crucial to case/match as used in Scala and functional programming in general.

wtetzner 10y ago
It is not crucial for functional programming, unless your functional programming language uses types as variant tags. Both Haskell and OCaml use type erasure, and I doubt anyone would claim they aren't functional languages.
- danarmak 10y ago
  If they store a variant tag, that means they don't erase the bit of info that's needed for case matching. My point is that it's crucial to be able to tell at runtime to which (sub)type a value belongs. Other type information that isn't necessary for that can still be erased.
  - wtetzner 10y ago
    I think we're in agreement, and just tripping over terminology. In most functional languages, values in a variant are just values in that variant. They don't each have their own type, which means the variant tag isn't actually type information.

zigzigzag 10y ago

You can observe it on the JVM when you realise you can't overload a function with arguments that differ only in generic type.

wtetzner 10y ago
Yes, my point was that there's nothing inherently wrong with type erasure. You can of course create conditions that would be problematic, like the design of Java and JVM does.