[MLton] deepFlatten exception

[Matthew Fluet]

>> The tricky part isn't MLton_eq introduced as part of the
>> implementation of MLton_equal (polymorphic equality); the tricky
>> part is direct usage of MLton_eq by the user as MLton.eq.  Then it
>> isn't so clear to me that it's OK to say they're not equal if we're
>> not sure.
>
> Actually, that's the situation I was thinking of.  Just as MLton_eq is
> used by MLton_equal to optimize polymorphic equality, I would think
> that the only sensible use of MLton.eq by a user is to optimize some
> other notion of equality where they don't want to pay the full cost of
> polymorphic equality if MLton.eq returns false.

Right, but the question is whether:

val z = (1,2,3,(4,5,6))
val y = z
val b = MLton.eq (z, y)

should ever reasonably return false.  That is, I could imagine that 
another (possibly) sensible use of MLton.eq by a user is to assert that 
some expected sharing is actually happening.  But, it may be that the 
optimizer never guarantees that.

> Given that our documentation says "the semantics is a bit murky", I
> think we have free reign.  We could add something to the documentation
> about the intended usage and that we feel free to conservatively
> return false when we're unsure.  We could also ask Joe what he's using
> it for, or ask on MLton-user for feedback.

Looks like he's using it for 'randomly balanced tree' operations; one 
usage is in the 'equal' function, but there are also uses for the 
'union', 'intersect', and 'differenc' functions.  They all appear to use 
Mlton.eq for optimization, and all have reasonable cases for the false 
case.

> Perhaps this is all moot since we're not going to tweak the
> deepFlatten transformation.

Fair enough.