Unpack primitive types by default in data

Jean-Marie Gaillourdet jmg at gaillourdet.net
Fri Feb 17 11:42:48 CET 2012


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

Starting with Java 5, javac automatically boxes / unboxes between a primitive type and its corresponding reference type. I.e. the programmer still specifies how a value is stored. This autoboxing simply makes them assignment compatible. As far as I understand it, auto boxing was introduced in order to better integrate primitive types with generics, not as an optimization. And I doubt that it is an optimization on average.

I think, It might still be a good idea to realize Johann's proposal. I am just cautious whether Java really shows that this is a good idea.



More information about the Glasgow-haskell-users mailing list