Unpack primitive types by default in data

[Johan Tibell]

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.

-- Johan