3 ms·

As a Haskell aficionado I can appreciate type erasure and the idea that you don't need to know shit at runtime. However yes when using hybrid languages like C#

As a Haskell aficionado I can appreciate type erasure and the idea that you don't need to know shit at runtime. However yes when using hybrid languages like C# you have to cheat sometimes. Although anything that uses reflection makes me cringe and there is the practical concern that analysis tools such as find all references etc. are of less use when there is stuff going round and reflecting on shit.

daxfohl 9y ago
This seems orthogonal though. Just because a runtime uses reified generics, doesn't mean that it has to provide reflection on them. 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?
- masklinn 9y ago
  > This seems orthogonal though. Just because a runtime uses reified generics, doesn't mean that it has to provide reflection on them. 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.
- lmm 9y ago
  Sure you could put reified generics in there, but what would you use them for if you didn't have reflection?
seanmcdirmid 9y ago
If you admit dynamic casts/tests in your language, then why go only half way? Such inconsistency leads to bad usability. Haskell is at the other extreme (no dynamic casts) but then it is consistent about it.
paulddraper 9y ago
Yeah. People complain about Java type erasure, but the problem is not that they have type ensure, it's that they did it only halfway.
- orclev 9y ago
  Yeah, I can see that. Basically you've got two options, go the Haskell way and have zero runtime reflection support and full type erasure, or go the C# way and have full reflection support and no type erasure. Java it's just painful because you get runtime reflection except it's incomplete because half the type info was erased at compile time.

daxfohl 9y ago

This seems orthogonal though. Just because a runtime uses reified generics, doesn't mean that it has to provide reflection on them. 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?

masklinn 9y ago
> This seems orthogonal though. Just because a runtime uses reified generics, doesn't mean that it has to provide reflection on them. 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.
lmm 9y ago
Sure you could put reified generics in there, but what would you use them for if you didn't have reflection?

seanmcdirmid 9y ago

If you admit dynamic casts/tests in your language, then why go only half way? Such inconsistency leads to bad usability. Haskell is at the other extreme (no dynamic casts) but then it is consistent about it.

paulddraper 9y ago

Yeah. People complain about Java type erasure, but the problem is not that they have type ensure, it's that they did it only halfway.

orclev 9y ago
Yeah, I can see that. Basically you've got two options, go the Haskell way and have zero runtime reflection support and full type erasure, or go the C# way and have full reflection support and no type erasure. Java it's just painful because you get runtime reflection except it's incomplete because half the type info was erased at compile time.