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 ---------------------------------------------------------------------------