Hi David,
I'd prefer a function of the type "timeout :: Int -> IO a -> IO a" which just throws the exception when there's an error. I like exception handling.
A timeout event can be signaled using both exceptions and a return code ('Nothing'), and there are valid arguments that favor either approach. In my humble opinion, an exception is an _exceptional_ event. It is something you didn't expect to happen. When I read from a socket, but that socket doesn't work anymore because the peer suddenly closed the connection, then that is something I want to have reported as an exception. When I read from a socket, but can't because the input stream has reached EOF, then that is _not_ an exception, that is EOF, a state every stream reaches eventually. In terms of timeout, I prefer the "Maybe a" return type because when I say "timeout n f", a timeout event is an expected result, not an unexpected one. Besides, the computation timeout n f >>= maybe (fail "timeout") return is no major effort to write and has the neat advantage that it doesn't dictate the type of the exception thrown in case of a timeout. I like the fact that the dynamic exception used internally isn't visible on the outside.
Another question is whether we could have a nicer type for the time argument.
Originally, the module exported "type MicroSeconds = int" to make things a little more readable, but in the end it felt odd to have System.Timeout export a MicroSeconds type. The signature we have now isn't perfect, but at least it's consistent with hWaitForInput and threadDelay. If there is a concrete type the code could use, I'm all for using it, but I'm against delaying the inclusion of timeout for another couple of years because we don't have a type for microseconds right now. Best regards, Peter