[MLton] bug with packed representations

[Matthew Fluet]

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

I agree completely; and I think MLton (with the exception of this bug) is
maintaining that distinction.  I was very careful with the way I phrased
the above, because in the Representation SSA (RSSA) IL and the Machine IL,
what is meant by a value, representation, and type are fast moving
targets.  It becomes confusing to say that the Machine IL Cast should not
change the representation -- because it looks like it is taking something
with one _representation (type)_ to another.  To put it another way, in
the Machine IL the values are operands (i.e., bins of bits), types are
representations (i.e., how one interprets those bits) and the
representations are word sizes (i.e., how many bits).

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

I don't think we'll have any issue with the primops.  Anything that
corresponds to a coercion in the Machine IL will correspond to changing
from one word size to another (or shifting bits around), and all those
primops are there; indeed, a whole family of WordX_toWordY primops.