On Fri, Feb 17, 2012 at 3:13 AM, Roman Leshchinskiy
True, I didn't phrase that right at all. AFAIK, in Java, there is a one-to-one correspondence between a primitive type and its boxed version. So you can say that boxed integers will be unboxed when necessary and it's clear what that means. But in Haskell, there is no such one-to-one correspondence. This is a very good thing but it makes specifying and understanding what will be unboxed when much harder.
You're right that it's harder to specify exactly when unpacking happens but default is better, both if you know how it works and if you don't. - If you don't know how it works (e.g. you're a beginner/intermediate level Haskeller) the default is saner. - If you know how it works you don't have to write all these UNPACKs that sit on every single primitive field* in our core libraries. * I did a quick count of how many primitive fields are manually unpacked in text, bytestring, and containers. Here are the results (unpacked/total): text: 27/30 Not unpacked: Data/Text/Lazy/Builder/Int.hs:data T = T !Integer !Int Data/Text/Lazy/Read.hs:data T = T !Integer !Int Data/Text/Read.hs:data T = T !Integer !Int These three seem all to get their boxed removed anyway as they're just used as a return type and get turned into (# Integer, Int# #) anyway. An unpack here wouldn't have hurt. bytestring: 3/3 containers: 13/13 I would be interested to see if there's a case where primitive fields aren't unpacked and that's not a misstake. -- Johan