[MLton] deepFlatten exception
Stephen Weeks
sweeks@sweeks.com
Wed, 21 Jun 2006 14:07:17 -0700
> So, this requires the arguments to MLton_eq to have the same flattening
> behavior: either they are both flattened or they are both not-flattened.
>
> The diagnostics of the deepFlatten pass show that the arguments are
> determined to be flattenable:
...
> But, the transformation pass can't handle Flat arguments to primitives.
>
> First off, I note that if we change the analysis of primitives to:
...
> | MLton_eq => dontFlatten ()
> | MLton_equal => dontFlatten ()
...
> then the program compiles without error; this effectively forces the
> arguments of MLton_eq to be NotFlat, which transforms without problem.
I'd say that the right fix is to leave the cases alone and to change
the definition of equal to
fun equal () =
(Value.unify (arg 0, arg 1)
; dontFlatten (arg 0)
; result ())
The difference being that the call to unify meets the requirement that
the two arguments to an equality test have the same type.
> If we wanted to allow flattening of MLton_eq arguments, then we need to
> correctly handle the transformation.
Yeah. Since we've lived this long without it, I'd say it's OK to do
the above and not muck with the transformation.
> (Interestingly, and possibly a missed opportunity for optimization, in the
> test program, the pointer equality would necessarily evaluate to false,
> since one of the tuples is freshly allocated in the block.)
Good observation. We need a public list of missed optimizations on
the wiki, to which this one should be added.
> It may be that this implies that we can't flatten arguments to MLton_eq,
> since I don't see how to encode the right semantics.
MLton_eq is murky, but I'd say the right thing to do in this case
would be to return false. The thinking being that MLton_eq is about
optimizing other equality tests, so we should be sure that things are
really the same when we say they are (return true), but it's OK to say
they're not equal if we're not sure.