Re: Concerning Time.TimeDiff

I'm going to offer what is probably a contrary view in this community. I find myself concerned about the direction of this discussion, but am having some trouble figuring out whether my concerns are justified or over-conservatism. My concern is that in pursuit of perfection we may sacrifice utility. (Or: "the best is the enemy of the good".) On any hardware than I'm familiar with, processing rationals, or unlimited precision numbers, is significantly more expensive than using the native machine capabilities. So, does the cost of using rational (or indefinite precisions) fopr time calculations sufficiently justify the benefits, especially when every program that uses the common library function must pay those cost? I think the answer partly depends on what kinds of application Haskell will be used to implement. If the view is that Haskell is primarily for writing programs that are provably correct in all conceivable circumstances, then the case for using rational time values is clear. But (partly inspired by Backus back in 1978, and the very practically useful work of the Haskell community in developing the language and tools) I see Haskell as something far more approaching a "mainstream" programming option. I think the evolving work on type-safety and generics gives Haskell real potential value in an "industrial" setting, where the errors of concern are usually not about losing leap-seconds, or software that will still be operationally correct millennia from now, but rather about will it help us deal with the increasing complexity of application design without leaving stupid trapdoors for accidental or malicious subversion of the code. I guess that reasonably efficient 64-bit support is pretty much universal on any machine (with a little software assist) I can imagine running Haskell, and I note that 64 bits (about 10^19) comfortably holds a second's worth of picoseconds. A rough calculation gives 2^64 picoseconds = 5000 hours, so 64 bits clearly isn't enough to hold all useful dates in picoseconds. 2^64 seconds is enough to represent many more years than I could shake a stick at (something like 5*10^11 years). Dealing with sub-picosecond intervals is something I find hard to imagine being a common requirement (I may often talk about nanoseconds in the context of computers, but I've never really had to compute with them: milliseconds has been about the smallest I've had to deal with). My point is that seconds and picoseconds, represented using 64 bit binary values, are a pretty efficient engineering choice that I think will satisfy a vast majority of the requirements of actual applications that use a common time library, and which don't hold any potential performance pitfalls. I could, of course, be wrong and short-sighted in this view, but I find it hard to lose sleep over missing leap-seconds and dates beyond the lifetime of the Universe(?) for the majority of applications built using a general-purpose programming system. And the cost of supporting all this may be trivial in practical terms -- I don't have a good handle on that, but I'll comment that time calculations might be a significant computational burden for a real-time system dealing with high event rates (and I think we'll see lots of these applications). #g -- At 13:09 18/06/03 -0400, Dean Herington wrote:

"Ketil Z. Malde" wrote:

...

"Simon Marlow" writes:

...

- ClockTime and TimeDiff are now represented as Integer picoseconds only. Hence, they also now derive Num, Enum, and Integral.

I think this is the most aesthetically pleasing. From a practical point of view, we should perhaps consider the possible need to represent times of higher resolution, and the practical need to use of much lower resolution. Division by 10^12, or the need to push really large integers around isn't going to end up being costly, is it?

Representing times as `Rational` seems more elegant: * It handles widely varying needs for resolution nicely. * It avoids choosing picoseconds as the finest possible resolution. What are the downsides to `Rational`? And if those downsides are serious enough, it would seem that the next best approach would be to represent times abstractly.

Dean

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

------------------- Graham Klyne PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E