3 ms·

I seem to be missing the implication as well. I am under the impression that Haskell relies on boxed values primarily due to its parametric polymorphism. There

I seem to be missing the implication as well. I am under the impression that Haskell relies on boxed values primarily due to its parametric polymorphism. There is a Simon Peyton Jones talk somewhere discussing the acrobatic GHC requires for the type theory to deal with unboxed types and their implicit requirement for an alternative Kind at the type level. The laziness as a default just makes boxing closure values a sensible default, when the type system requires the boxing of everything in general.

benreesman 2y ago
On everything from the JVM to GHC to v8 there is a critical distinction between the semantics of a boxed type and the practical outcome on the gear. Every managed language runtime done by pros (and those all are, I should have said the CLR too) will quietly unbox in all the easy cases and some of the hard ones. Parametric polymorphism is kind of orthogonal to that. It’s related I guess. It can involve some kind of runtime dispatch, but usually that gets JITed or inlined or whatever unless you really insult the compiler. And even full frontal invokedynamic it’s still like, is it in the BTB and the I-cache? Ok well we’re still doing business.