Real.maxFinite and friends

[Matthew Fluet]

> The only real problem in my mind with making real be 80 bits (and not having
> something like Real64 and Real32) is arrays.  I.e., the space occupied.
> Also I guess communication with ffi stuff.  I.e., if I only have 80 bit
> reals, then I will be upset if I test to see if something isFinite, and
> yet when I send it to the foreign code it gets infinity because of the
> fact that 64 bit reals have fewer exponent bits.

Well, I think this is just an issue of making sure that types work out.
Real80.real, Real64.real, and Real32.real will all be distinct.  We decide
which of these belong in the u class of types allowed in the grammar of
types describing _ffi's.  (Real64 would probably be a given.)  I don't
even think we would need MLton.Real.to64.  The basis library functions
Real.{to,from}Large provide those conversions.  Now if you want to call a
math.h function, which wants 64 bit floats, then you need to convert them,
and you understand that you are losing precision.

As for the space, that's a little harder.  But, I think it's the standard
time/space(/complexity) tradeoff.  If you want 64 bit float arrays, then
either you work in 64 bits (and pay the penalty of banging in and out of
memory), or you convert to and from 80 bits at sub and update (that's the
complexity).  Or you pay the space and always work in 80 bits.