[MLton] an analysis to flatten refs into tuples

[Stephen Weeks]

> From the rest of your mail, you don't seem to consider the more
> general case of flattening into datatypes.

I was planning to treat n-ary constructors just like n-ary tuples,
except that the flow analysis will merge all uses of a constructor
together, while it may distinguish different occurrences of the same
tuple type.

> > The local analysis checks when a ref creation corresponds
> > to a tuple creation (i.e., we see val x = ref y; val z = (x, w)) and
> > when a ref that is extracted is only ever assigned to (i.e. we see val
> > r = #2 z; val () = r := x).
> 
> Don't you also want to allow a dereference in the project case?

Yes.

> I don't know if your examples above were meant to imply that the local
> analysis was _really_ local and exclusively looking for these patterns, or
> if you were considering a more general, but still local analysis.

More general, but still local.  Those were just examples.

> This local analysis reminds me a lot of the local ref analysis.  And, I
> think you need to be concerned with the same problems of escaping refs.
> Remember, in the multi-threaded case, a ref can also escape to the stack
> across a non-tail call.

True, a ref can escape to the stack, but I don't see how that
invalidates flattening it into the tuple, because flattening will then
cause the tuple to escape into the stack.  The difference from
local-ref seems to be that the mutability is not being changed, we're
simply changing the data structure where the mutability is.