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

Edward Kmett ekmett at gmail.com
Thu Apr 21 11:52:56 CEST 2011


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 at gmail.com> wrote:

> On Wed, Apr 20, 2011 at 22:31, Neil Mitchell <ndmitchell at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110421/bd07c70b/attachment.htm>


More information about the Libraries mailing list