[MLton] deepFlatten exception
Matthew Fluet
fluet@cs.cornell.edu
Wed, 21 Jun 2006 22:55:43 -0400 (EDT)
>> 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.
That looks good.
>> 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.
Agreed.
>> 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.
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.