[MLton] an analysis to flatten refs into tuples

[Matthew Fluet]

> In fact given the code above, I expect MLton to be able to flatten any value
> of type ('a,'b) mpair. Of course the reason I expect this is because of
> type-abstraction. I'm not so clear if MLton can exploit this
> type-abstraction info in the ref-flattening analysis. If would be very nice
> if it did.

I think there is a general tension between aggressive optimizations and
user specified optimizations.  One of the nice things about SML (IMHO) is
that the compiler is free to represent things however it wants; when you
start letting the programmer tell the compiler how to represent things,
you end up introducing constraints on what the compiler can do.

Also, note that the flattening pass runs after monomorphisation,
defunctionalization, inlining, etc.  By the time we would check the user's
annotation, a lot of things may have changed.  The mutable tuple itself
might have been flattented (i.e., two refs are passed around, rather than
a pair of refs), one or both of the components are determined to be
unused (and simplified away), etc.  In both of these situations the ref
flattening cannot occur, but it's not the programmer's error.  Trying to
weed out when a ref can't be flattened because of the source program or
because of some simplification would be really hard, I would imagine.