[MLton] array flattening

[Stephen Weeks]

> Oh yes.. please document a magic prim/type con. so the programmer can be 
> guaranteed that The array flatter won't "do the wrong thing".
...
> type 'a boxed
> val box: 'a -> 'a boxed
> val unbox : 'a boxed -> 'a

This seems quite reasonable, and fairly easy to implement.  I'd
certainly go for the primitive type (not the datatype).

> While, we are on the subject
> type 'a ext_rep
> val toExtRep: 'a -> 'a ext_rep
> val fromExtRep: 'a ext_rep -> 'a
> 
> where "ext_rep" means external representation. i.e. tell MLton to turn off 
> all data representations for this type. 

I don't like this at all.  There is no such thing as a standard
representation for SML types.  We've exposed a few representations for
our FFI, but exposing more will just tie our hands and make the
whole system and user code more brittle.

> So I can portably access the structure via C or some other evil FFI.

The right way to do this is to use our existing _export mechanism to
export accessor functions.  That way, MLton, and only MLton, knows all
the representation stuff, and speaks the standard C FFI that other
systems already know.