[MLton] bug with packed representations

[Daniel C. Wang]

Matthew Fluet wrote:

{stuff deleted}
> Unfortunately, projecting the low bits via a Cast doesn't mesh well with
> the x86 codegen's translation of a Cast:
> 
> 	  | Cast (z, _) => toX86Operand z
> 
> And I think this is the correct interpretation.  Thus far, we've only used
> Cast to indicate that we were changing our interpretation of bits, but not
> the actual bits themselves (or the number of bits).  So the toX86Operand
> just car's down the Casts, ignoring the types, to get to a base operand
> that corresponds to some actual bits (or a location of bits).
{stuff deleted}

The type-theory weenies, typically distinguish between "casting" and 
"coercing", where casting a value to another type is a nop with respect to 
representation, but a coercion may make a representation change. If the 
primop approach doesn't work (I imagine you need a family of primops to do 
this right). I'd suggest introducing a new constructor distinct from "Cast" 
and call it "Coerce".