February 2005 - Libraries

bracketOnError, while, forever
by Peter Simons 08 Feb '05

08 Feb '05

Hi, I just found the rather useful function 'bracketOnError' in Network.hs and was wondering why it is not exported. You need this combinator every time you fork off a computation with an acquired resource, which happens pretty often in network code, so I think making it available would be worthwhile. On a similar note, I find myself using two rather simple combinators frequently but have no place where to put them: while :: (Monad m) => m Bool -> m a -> m () while cond f = cond >>= flip when (f >> while cond f) forever :: (Monad m) => m a -> m () forever f = while (return True) f 'while', at least, would a nice addition to Control.Monad, IMHO. Peter

6 5

RE: System.Time.Clock Design Issues
by Udo Stenzel 07 Feb '05

07 Feb '05

"Simon Marlow" <simonmar(a)microsoft.com> schrieb am 03.02.05 14:47:39: > On 03 February 2005 13:01, Ashley Yakeley wrote: > But I agree with the rest of what you say. Basically, providing TAI > time is problematic because we can't implement it correctly, for future > times, on systems that only provide POSIX time. > > At this point I'm not sure what is best, I'm still quite disturbed by > the idea of basing the definition of the Haskell Time library on what is > basically a mistake in the definition of POSIX :-) Somehow I fail to see the problem... Basically we need two different representations of time anyway, a calendar and something like TAI. The calendar is necessary for everyday operations, like rolling the date field. This can't be done by adding seconds to any counter: adding 86400 seconds to get to the next day fails at least twice a year when switching from/to DST. The "number of seconds" is necessary for timestamping. The way I see it, both worlds almost never intersect, the only contact points are formatting time stamps and converting the current system time to calendar time. Suppose we settle for TAI and a separate calendar. We also assume, the system clock provides TAI, maybe allow an offset to be configured. If the system time is TAI indeed, all is well. Conversion to calendar time will always work, because we only convert dates in the past, where leap seconds are known. Assume the system provides UTC or POSIX time or something like that. Then our time stamps will still work, as they are still monotonically increasing. Nothing fails, only the conversion to calendar time will be off by around 20 seconds. So what? If the modification time of a file is off by some seconds, probably no one will notice. Same for the current time, most often. If these few seconds matter, the offset could still be "configured away", and who cares if it isn't reliable or exact, the system time was broken to begin with. Therefore, TAI + calendar + (optional) a fixed offset. What am I missing? Regards, Udo. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

7 14

RE: Data.Graph patch
by Simon Marlow 07 Feb '05

07 Feb '05

On 31 January 2005 22:20, John Meacham wrote: > Here is a patch for Data.Graph which fixes an oversight in > graphFromEdges. graphFromEdges returns a function which turns vertexes > into nodes, but provides no way to go the other direction and figure > out which vertex goes with a node. I simply return the already created > function of type key -> Maybe Vertex in the tuple. > > I provided it as a new function > graphFromEdges' and left the old functionality under the old name. if > we don't care about backwards compatability, I'd recommend just > replacing the one that is already there since it is a more complete > interface and an easy transition for anyone currently using the > library. Committed, replacing graphFromEdges. The old one is now called graphFromEdges'. Cheers, Simon

1 0

RE: Typeable SockAddr
by Simon Marlow 07 Feb '05

07 Feb '05

On 07 February 2005 00:28, Peter Simons wrote: > I was wondering: Is there any reason why SockAddr (and other > types in Network.*) are not instances of Typeable? Now added. Cheers, Simon

1 0

RE: System.Time.Clock Design Issues
by Bayley, Alistair 06 Feb '05

06 Feb '05

> From: Ketil Malde [mailto:ketil+haskell@ii.uib.no] > > I don't think this is correct. In UTC, extra leap seconds are denoted > 23:59:60 and the missing ones have :59:58 as the last second. Posix's > seconds are thus not isomorphic to UTC. Ahh, yes, sorry: http://cr.yp.to/proto/utctai.html http://tycho.usno.navy.mil/systime.html http://www.boulder.nist.gov/timefreq/pubs/bulletin/leapsecond.htm I should read more... So UTC and UT1 seem to be more-or-less equivalent, in that they both include leap seconds. UT1 measures the actual earth day (so I assume it has some fractional component for seconds), while UTC (which I assume counts integral seconds) tracks UT1 with an error of +/-0.9s. UTC "differs from TAI by an integral number of seconds". TAI ignores leap seconds, but does track time accurately by always ticking (i.e. not slowing down at a leap second). There are exactly 86400 seconds in a TAI day, so the day will drift w.r.t. the earth's actual day, whereas UTC tracks the actual day accurately by inserting leap seconds. So the TAI day isn't very useful. POSIX is "idealised" time, where days are always 23:59:59, and a second sometimes takes two seconds. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

4 7

RE: Type for Current Time Function
by Bayley, Alistair 04 Feb '05

04 Feb '05

> From: Ashley Yakeley [mailto:ashley@semantic.org] > > The most basic or at least the most obvious function in a > time library > is one that gets the current time. What is its return type? > > getCurrentTime :: IO ??? It looks as though POSIX should be avoided, so I vote for (days, ticks). Is there some reason it couldn't (shouldn't) be an opaque type? i.e. with functions to convert to-and-from: - (days, ticks) - seconds since epoch - Calendar Time (in various calendars and timezones, etc) - other arbitrary representations ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

4 5

RE: System.Time.Clock Design Issues
by Simon Marlow 04 Feb '05

04 Feb '05

On 03 February 2005 13:01, Ashley Yakeley wrote: > It's true that POSIX is an inherently wrong representation of UTC, as > it is wrong at leap seconds. The trouble is, what you are suggesting > is a type that is wrong in a much more complicated way: it starts off > as a correct representation of TAI, and turns into a representation > of UTC that is also wrong at leap seconds. > > Let us suppose we have a system clock that keeps POSIX time, and a > Haskell function, getClockTime, that returns the current ClockTime you > are suggesting. I compile a program that calls this function. > > At first getClockTime returns the correct TAI time, which can be > converted into the correct UTC time. Then, in two years' time, a leap > second is announced. During the leap second, the system clock is > stepped, and getClockTime returns the wrong TAI time converted to the > wrong (by up to a second) UTC time. After the leap second, > getClockTime continues to return the wrong TAI time, but it is > converted to the correct UTC time. Actually you'd probably get a correct UTC time, because the conversion would be done by first converting to POSIX time, and then asking the C library to convert to UTC. The errors cancel out. But I agree with the rest of what you say. Basically, providing TAI time is problematic because we can't implement it correctly, for future times, on systems that only provide POSIX time. At this point I'm not sure what is best, I'm still quite disturbed by the idea of basing the definition of the Haskell Time library on what is basically a mistake in the definition of POSIX :-) Cheers, Simon

5 6

RE: Type for Current Time Function
by Bayley, Alistair 04 Feb '05

04 Feb '05

> From: Simon Marlow [mailto:simonmar@microsoft.com] > > I think I don't really understand the (days,ticks) representation. > Could somebody explain the meaning of arithmetic on this type? > > Is the ticks field supposed to be limited to a day's worth? > Or a day + a leap second? I'm assuming that it's UTC (i.e. ticks = day plus optional leap second), although others might think differently... > Can I add ticks to a time? If so, don't you need leap second > info to do > the normalisation? Or, if normalisation doesn't happen, you need leap > second info to convert to UTC, right? The only conclusion seems to be > that either you can't add ticks to a time, or you need leap > second info > which is what we're trying to avoid. Isn't this a general problem, rather than a specific representation problem? The only representation where you wouldn't have to know about leap seconds would be TAI. E.g. there was a leap second on 1997-06-30 23:59:60 UTC, so: - Q: how many seconds are there between 1997-06-30 00:00:00 UTC and 1997-07-01 00:00:00 UTC ? A: 86401 - Q: how many days are there between 1997-06-30 00:00:00 UTC and 1997-07-01 00:00:00 UTC ? A: 1 - Q: how long is the period between 1997-06-30 00:00:00 UTC and 1997-07-01 00:00:00 UTC ? A: 1 day 1 second, or 1 day ? (I guess just 1 day, as a day can be 86401 seconds long.) - Q: how many seconds in a day? A: 86400 (or maybe this is undefined, as it could be 86399, 86400, 86401?) - Q: what is 1997-06-30 00:00:00 UTC plus one day? A: 1997-07-01 00:00:00 UTC - Q: what is 1997-06-30 00:00:00 UTC plus 86400 seconds? A: 1997-06-30 23:59:60 UTC It gets hairy when you start thinking about durations, and I would like to see duration arithmetic in the library. I don't have any good ideas about how to handle this. Alistair. ----------------------------------------- ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

1 0

RE: System.Time.Clock Design Issues
by Simon Marlow 04 Feb '05

04 Feb '05

On 04 February 2005 11:00, Glynn Clements wrote: > Simon Marlow wrote: > >> The time zone issue is a red herring. You can use UTC calendar time >> exclusively if you want. > > I'm not entirely sure what you mean by that, but you need local > calendar times for date arithmetic, e.g. "one month from now": Yes of course. That comment was in reply to Ashley's comparison of POSIX time and calendar time, where he said that "calendar time ... may be dependent on timezone". I was just pointing out that the fact that calendar time includes the timezone is not a limitation. Cheers, Simon

1 0

System.Time.Clock Design Issues
by Ashley Yakeley 04 Feb '05

04 Feb '05

Time turns out to be complicated by nature, and it's not possible to be as simple as we'd like and still be completely correct: there's a trade-off between simplicity and correctness. I lean towards correctness myself, I think there are ways of managing extra complexity. We might, for instance, be able to separate some of the less-used functions into another module fairly sensibly. There's also a trade-off between simplicity and usefulness. My earlier message has one idea of where to draw the line, as well as one way of splitting the functionality: <http://www.haskell.org//pipermail/libraries/2005-January/002930.html> Simon suggested naming the two modules "System.Time.Clock" and "System.Time.Calendar". These are the issues that seem to be remaining for the "Clock" module: * Can we assume that gettimeofday always returns UTC rather than TAI time? POSIX says yes. People might set it differently, but there doesn't seem to be any way of detecting that. We can't used time-zone setting AFAIK, because gettimeofday is supposed to be universal time independent of time-zone. My preference is to assume people are following the POSIX standard, since that's the assumption that most software makes (including NTP I believe). * Should there be a TAI type separate from a POSIX time type that the system clock would return? My preference is yes. If necessary we could create a third module for TAI time and explicit leap-second handling, which will keep them out of the way for most people. Separate types is more complication, but the alternatives have their own issues: <http://www.haskell.org//pipermail/libraries/2005-February/003049.html> * What resolution should we use, and should it be platform-dependent? My preference is (platform-independent) picoseconds to match the existing System.Time library and as a hedge against Moore's law. * Should we include a (days,ticks) UTC type separate from the POSIX time type? I have two reasons for wanting this. Firstly, correctness: the POSIX time type cannot represent leap seconds, whereas this can. Secondly, this holds the result of a useful function that splits POSIX time into the simplest possible date and time parts, which can then be used for converting to various internationalised calendars. -- Ashley Yakeley, Seattle WA

5 8