BTW there's a compromise with unboxing that also has benefits, which is embedding. An [@embed] annotation could turn an array into an embedding array, for example. This would mean that an array would have boxed members within it ie. not accessible via pointers. The advantages are better cache performance and that the GC could be instructed when the array is completely flat ie. an embedded array without any pointers could be skipped by the GC in the mark phase. It would have full polymorphism capability.

The down side is that deallocating the array without deallocating the embedded structure would be tricky. When deallocating, you have to check every member to see if it should be deallocated as well. If not, you copy the member (minor heap) or reallocate the member where it is in memory (major heap).

Yotam


On Wed, Jan 29, 2014 at 11:11 AM, Yotam Barnoy <yotambarnoy@gmail.com> wrote:

On Wed, Jan 29, 2014 at 3:32 AM, Jon Harrop <jon@ffconsultancy.com> wrote:
Yotam wrote:
> Of course, once you unbox, all parametric polymorphism is lost

Is it?


It is in haskell. In general, I don't think you can do any parametric polymorphism without metadata.
 
You would have to box the tuple before passing it to a polymorphic function
with the type 'a -> 'a. However, if the function has the type 'a * 'b -> 'b
* 'a then you could always unbox, right?


I don't think so. Without metadata, how do you know where one tuple member ends and another begins?

Yotam