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 <hesselink@gmail.com> wrote:
On Wed, Apr 20, 2011 at 22:31, Neil Mitchell <ndmitchell@gmail.com> 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