[MLton] array flattening

[Daniel C. Wang]

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". Especially, 
when I plan to copy array's a lot, or am relying on the implicit pointer 
sharing for some algorithmic improvement.

I'd suggest introduction a new data con.

datatype 'a boxed = B of 'a

or maybe

type 'a boxed
val box: 'a -> 'a boxed
val unbox : 'a boxed -> 'a

If someone like Henry is really worried about this he can create an array of 
boxed elements, and feel safe that things behave the way they should! If I 
remember correctly SML/NJ always boxes datatypes even nullary ones, because 
users expect this representation when writing programs.

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. So I can portably access the 
structure via C or some other evil FFI.

Henry Cejtin wrote:

> I  am  very  interested  in what the array flattening thing will do since its
> lack is one of the biggest space inefficiencies that I see in generated MLton
> code.   Despite  that,  I  guess that it will cause some things to get worse.
> E.g., if I create an array with
>         Array.array (1000000, (0, 0))
> then it currently that takes only 4 bytes per element, while, I assume,  your
> proposed optimization will flatten out things, so it will be 8 bytes per.
>