Concerning Time.TimeDiff

John Meacham john@repetae.net
Fri, 20 Jun 2003 13:12:03 -0700


I was going to suggest this too, my only reservation is that the
internal representation not having as much accuracy as the user expects
might cause problems. however, I am not sure how big of a concern this
is. In any case the user can always come up with their own datatype if
they need too. Since the ClockTime routines won't work outside of the
natural range of the implementation, perhaps we should expose a way for
the user to get at the leap second tables so that they may use that info
when implementing their own clocktime types.
        John


On Fri, Jun 20, 2003 at 02:42:58PM +0100, Simon Marlow wrote:
>  
> > > in any case, since a pair of Int64's is not a clear win and 
> > an Integer
> > > definitely is a clear win in terms of usability then I 
> > believe we should
> > > go for that.
> > 
> > It's a radical idea but... Maybe we could avoid all these 
> > issues by using an 
> > abstract type with all sensible instances (including Num 
> > though it is only 
> > semi-sensible for times).
> >
> > Internally, we might use Integer or two Int64s or we might 
> > even add Int128 to 
> > our compilers.  Externally it looks like an Integral (or 
> > Fractional?) type.
> 
> Yes, I think that's a reasonable compromise.  The accuracy is still
> specified to be picoseconds, but the representation is hidden.
> 
> Any objections?
> 
> Cheers,
> 	Simon
> _______________________________________________
> Libraries mailing list
> Libraries@haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
> 

-- 
---------------------------------------------------------------------------
John Meacham - California Institute of Technology, Alum. - john@foo.net
---------------------------------------------------------------------------