Is there something special that type erasure adds, that you couldn't have Haskell without it? From a layman's perspective it seems that Haskell could be implemented with either an erased or a reified generics model under the hood, without changing the public surface of the language. But is there something that type erasure enables that reified generics does not?
It's not completely orthogonal as erased generics are annoying/problematic when the language does provide reflection/RTTI.
So you've got 4 (reification x reflection) states 3 of which are fine:
* if you have erasure and no reflection (Haskell) you're fine: you don't have runtime types but they don't matter/are inaccessible
* if you have reification and reflection (C#, C++/RTTI) you're fine: you can access runtime types and have them
* if you have reification and no reflection (Rust, C++/noRTTI) you're fine: you can specialise & discard types at runtime
* if you have erasure and reflection (Java) you're fucked: you can access types at runtime, but many aren't here anymore
> From a layman's perspective it seems that Haskell could be implemented with either an erased or a reified generics model under the hood, without changing the public surface of the language. But is there something that type erasure enables that reified generics does not?
A simpler implementation.