Time.time

[Stephen Weeks]

> I don't care about Time.time being an IntInf.int, but what is this worry about
> overflow?  It will happen when the clock overflows, and until we get to 64
> bit machines it is going to be a problem.  When we get there, which we will by
> then (then being the year 2033).  Then we will move it to be an Int64.  Game
> over for 292 billion years.

The worry is that the code is marginally more complicated  because it has to
worry about Overflow.  Definitely not a big deal.  Also, the basis library spec
for time uses LargeInt in the interface, which means we have to go through
conversions.  It works fine for SML/NJ because for them LargeInt = Int32.  For
us, it costs.  It might even be faster if we just used LargeInt, since we would
mostly be using the smallInt cases in the IntInf implementation.

Anyways, I'd still like to see Real.{from,to}LargeInt, but clearly nobody is
clamoring for them.