Re: Stop using "Int" for microsecond delays in "base"

The problem that I have with NominalDiffTime in general is that it is impossible to work with efficiently. There is no mechanism for extracting the integral number of picoseconds represented without round tripping unnecessarily through Rational. This isn't a problem for something like Delay, but I hesitate to push for increasing its adoption. For general purpose time manipulation where I need to manipulate a lot of these kinds of deltas such as in FRP, I've had to abandon the time API entirely because of the overhead. =( I appreciate Ashley's desire to retain an opaque API so that he can freely change the internal implementation, but such opacity comes at a cost of suitability in many cases. More importantly, there is also a layering problem. NominalDiffTime is in 'time', which depends on 'base' and threadDelay is in 'base'. -Edward On Thu, Apr 21, 2011 at 4:01 AM, Erik Hesselink wrote:

On Wed, Apr 20, 2011 at 22:31, Neil Mitchell wrote:

...

...

I always end up with a wrapper around it, taking a NominalDiffTime; I could never be sure whether threadDelay interpreted its argument as milli-/micro-/nano-seconds without looking it up.

I too always end up with a wrapper, but my wrapper takes a Double, which is in seconds. Seconds are easy, and a Double means that you can specify ridiculously long intervals, and for short intervals you have high precision. I find it much easier to write sleep 5, when I want to sleep for 5 seconds, than putting in some multiplication factor.

Note that NominalDiffTime has all the necessary instances to able to do the same. I.e. (5 :: NominalDiffTime), (5.123 :: NominalDiffTime), or (10^100 :: NominalDiffTime). These numbers are also interpreted as seconds, with a precision up to 10^-12.

Erik

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