38 ms·
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
by 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 agoSure you could put reified generics in there, but what would you use them for if you didn't have reflection?