Re: [Haskell-cafe] threadDelay delays less time than expected (Windows)

On 2016-12-29 19:54, Sven Panne wrote:

2016-12-29 17:27 GMT+01:00 Joey Hess mailto:id@joeyh.name>:

[...] It would perhaps be good for the documentation for threadDelay to point out that it can delay for a maximum of 71 minutes on 32 bit systems, and point to the unbounded-delays package.

.... or even better: Absorb the functions from unbounded-delays into base. In their current state, I would consider both threadDelay and timeout API bugs, see http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_revised.htm (/"//Make interfaces easy to use correctly and hard to use incorrectly."). /Perhaps we should add:

+1. Another, perhaps better, alternative would be to have something like a "TimeDiff" type in base, but an actual *duration* in *physical* time (no leap seconds, no calendar nonsense, etc.). This is one of those big mistakes almost everyone made in the past[1]. *Physical* time is so much different from *calendar* time that it really needs completely different representations and operations. (Of course there must be *some* way to 'convert', but those conversions are inherently dangerous and should be clearly marked as such.)

genericThreadDelay :: Integral i => i -> IO ()

I would be much happier with a signature of threadDelay :: Duration -> IO () with a few safe constructors for Duration, e.g. "daysToDuration :: Int -> Duration" and "millisToDuration :: ..." (etc.). We might arguably want "Maybe Duration" as the return type, but that may be pushing it. *THAT* is how you make this particular API hard to misuse. I don't know about you, but I always end up counting zeroes multiple times when writing a "threadDelay ..." line. Regards, [1] Bascially before JodaTime made ordinary developers aware of just how complex this Time/Date stuff really is and the importance of clearly separating the concept of "calendar" time vs. "physical" time.