[MLton-user] option ref optimized to a null pointer?

[Wesley W. Terpstra]

I was profiling and optimizing a message heap when I noticed that  
MLton.size suggests MLton is being especially clever.

It seems MLton represented the type '(int * int ref) option array' as  
I would have done it in C. It used an array of pointers to objects  
where each object is a pair of integers. So I pay 4+4+4 bytes per  
object (2 ints + header tag) and 12+4x bytes in the array (12 for the  
usual array overhead and 4 for each pointer).

What surprised me is that it seems MLton can turn the NONE case of  
option + pointer into a "null pointer". Is it my imagination, or is  
this really what's going on? Very cool. I guess this also applies to  
lists?

I was also happy to see that MLton had flattened the reference in the  
tuple away.

What rules must I obey to make sure MLton can continue to apply these  
optimizations? For the flattened tuple, I gather I shouldn't try  
ripping the 'int ref' out of the tuple and passing it through a  
function barrier. But  when does this 'option ref' -> 'null pointer'  
optimization happen? Always?

It might be nice if there were MLton representation guidelines  
somewhere. While it's nice that MLton just did the right thing, that's  
partly because I already knew not to break split the tuple with a ref. I
imagine there are other guidelines which I don't know.