[MLton] MLton.IntInf

[Stephen Weeks]

> Why not also the gcdext, inverse, powm, fdiv_r_2exp, and probab_prime?

I have no problem with those additional methods being exposed in
MLton.IntInf.  The reasons they are not there are lack of demand, lack
of understanding of the library on our part, and the fact that adding
IntInf primitives requires compiler mods.  IntInf stuff is harder to
handle than an ordinary FFI because it deals intimately with heap
allocation.  If you look at how IntInf.gcd is implemented, you'll see
some (unsafe) code in the basis library (integer/int-inf.sml) that
reserves the needed amount of space for the result.  You'll also see a
compiler primitive, IntInf_gcd, in atoms/prim.sig, whose semantics is
known to the compiler, and is expanded into the appropriate C call in
backend/ssa-to-rssa.fun.  Finally, there is a bit of runtime C code in
basis/IntInf.c that implements the call.

The upshot being that we don't have a nice abstraction for adding such
primitives, and that adding a new one touches quite a few places.  But
we would be happy for someone in the know to pattern match off of gcd
to implement the remaining ones and send us a patch.

> You might be interested to know that MLton knocks the socks off of
> OCaml for number theory applications. The ratio is sometimes as high
> as 35*. This is not just due to the GMP; when I use mlgmp, the ratio
> is still often 5*.

Neat.  Does mlgmp use the same trick as MLton to represent small
integers without using an indirection?  That can save a lot in some
cases.  If it's not that, I'd be interested to hear an explanation of
the difference.