Unpack primitive types by default in data

[Simon Marlow]

On 17/02/2012 18:34, Johan Tibell wrote:
> On Fri, Feb 17, 2012 at 3:13 AM, Roman Leshchinskiy<rl at cse.unsw.edu.au>  wrote:
>> 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.

I think there are some in GHC - I've been surprised occasionally when 
adding an UNPACK makes things worse.

Cheers,
	Simon