[MLton] Packing and IntInf

[Stephen Weeks]

> > Is this special representation necceary with the new packer? Could you
> > instead use the natural representation of:
> >         datatype t = Small of Int31.int | Big of bool * word vector
> > and have the packer decide on a similar representation ?
> 
> The representation packer should do the "right thing" with the natural
> representation; see
>   http://www.mlton.org/pipermail/mlton/2004-April/015766.html
> 
> But, we haven't modified the Basis Library code to take advantage of this,
> although it ought not to be that painful a process.

Because the C code must understand the representation of IntInf.int, I
think it's almost impossible to do for the datatype

	datatype t = Small of Int31.int | Big of bool * word vector

MLton doesn't guarantee anything about the representation of tuples,
so it won't be easy for the C side to construct the bool * word
vector.  It will also be difficult to communicate the correct tag to
use for Big from the SML code to the C side.  Also, using a tuple
instead of storing the sign in the first word of the vector creates an
extra indirection that costs more space and time.

It is possible to use

	datatype t = Big of word vector | Small of Int31.int

but it's still messy.  The C side must know that Small is implemented
with a low one bit.  This already fails with -representation unpacked
(fair enough, that will likely disappear someday, but in the meantime
I'd had to not be able to run IntInf benchmarks).  Also, in this case,
the C side can know the right tag for Big, because Big is represented
transparently and the tag for "word vector" is hardwired into the
runtime.

Anyways, if we're gonna define IntInf.int on the SML side and pass it
to the C side, it will certainly impose constraints on the compiler.
If we go this route we should consider changing the interface to the C
IntInf routines so that it is known statically as part of the type of
the C routine whether we are passing (or returning) a Small or a Big.
Then, we will only be passing Int.int or word vector, which we already
support in the FFI, and hence won't impose any new constraints.