[MLton] Re: [MLton-user] FFI and pointer relocation

[Matthew Fluet]

On Wed, 28 Nov 2007, Vesa Karvonen wrote:
> While, like Matthew, I don't feel that Time computations are
> performance critical, I see no harm in using 64-bit integers for time.

I think the only harm is the range of representable time values.
Now, since a lot of time functions are implemented by their C 
counterparts, I can see an argument for representing Time.time as
   datatype time = T of {sec: C_Time.t, usec: C_SUSeconds.t}
or
   datatype time = T of {sec: C_Time.t, nsec: Int64.t}
since then one would match the representable time values.

> However, I think that it is worth preserving the option to use IntInf
> time values.  Looking at the current Time implementation, it would
> seem fairly easy to turn it into a functor and parameterize it with an
> INTEGER module.

I like that idea; the difficulty is that representations like the above 
need a bit more work to get into the INTEGER signature.  Also, the INTEGER 
signature tends to bias conversions to going through the LargeInt.int 
type, so performance might suffer.

Better might be to have custom TIME_REP signature that makes the 
representation decision and provides the necessary (efficient) 
conversions, while leaving the represenationa independent portion of the 
implementation in a Time functor.

That's the kind of patch I'd welcome. ;-)