[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.