Unpack primitive types by default in data

[Roman Leshchinskiy]

Jean-Marie Gaillourdet wrote:
> Hi,
>
> On 17.02.2012, at 09:52, Roman Leshchinskiy wrote:
>
>> Johan Tibell wrote:
>>>
>>> The worry is that reboxing will cost us, but I realized today that at
>>> least one other language, Java, does this already today and even
>>> though it hurts performance in some cases, it seems to be a win on
>>> average. In Java all primitive fields get auto-boxed/unboxed when
>>> stored in polymorphic fields (e.g. in a HashMap which stores keys and
>>> fields as Object pointers.) This seems analogous to our case, except
>>> we might also unbox when calling lazy functions.
>>
>> I'm not convinced that this is a good idea because it doesn't treat all
>> types equally. The comparison with Java is problematic, IMO, because in
>> Java 'int' is always called 'int' whereas in Haskell, it might be called
>> many different things.
>
> Actually, there are two types for every primitive type in Java:
> int / java.lang.Integer
> byte / java.lang.Byte
> char / java.lang.Char
> float / java.lang.Float
> double / java.lang.Double
> ...

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.

Roman