[MLton] Compressed pointers

[Matthew Fluet]

Daniel C. Wang wrote:
> What about the following design, by default MLton is free to represent 
> any object however it likes. Introduce a new type constructor   'a 
> native, for the few cases where you want  the "native" representation 
> of  objects/values.

Personally, I think this is just more burden on the programmer.

> All heap pointers in heap objects that aren't "native" can be 
> represented as compressed pointers. 

 > Stack and registers only ever hold
> uncompressed addresses. 

That is a bit limiting.  Destructing and constructing data structures 
often rely on just shuffling pointers around; there's no need to 
uncompress them when they aren't being dereferenced.  So, I think it 
makes more sense for the stack to support both compressed and 
uncompressed pointers; its just two stack frame masks to differentiate 
the live pointers and the live compressed pointers.

> For the char** case, the ml_type would be something like
> 
> ((char array) native) array native

Sure, but my objection is that there is no point to the type
  (char array) array native
That is, you are passing over an array of opaque values; there is 
(almost) nothing that the C side can do with it.

> Making the "interop" issues explicit at the user level gives the 
> compiler more freedom and the end-user some more guarantees.

I don't think it gives the end-user more guarantees.  MLton doesn't 
guarantee anything about representations, except what is passed over the 
FFI (which is a much restricted set of types).  Better to just assert 
that any types which pass through the FFI will have their native C 
representation; the compiler takes care of the dirty work of coercing.

The important point is that we don't want to incur a deep coercion when 
passing a 'char array array' over the FFI; so, the compiler just 
arranges things so that pointers are uncompressed at the construction of 
the array; whole program analysis makes it easy to identify which arrays 
might flow through the FFI.