- Libraries - Haskell.org

RE: Time Libraries Rough Draft
by Simon Marlow 10 Feb '05

10 Feb '05

On 09 February 2005 11:24, Ashley Yakeley wrote: Looks good. A few minor commnets: > System.Time.LeapSeconds: I'd call it System.Time.TAI > module System.Time.Clock ( ... ) where > > -- | standard Julian count of Earth days > type JulianDay = Integer > > newtype DiffTime = MkDiffTime Integer Rather than exposing the constructor, I'd make it an abstract type with an instance of Integral. You probably want the Integral instance anyway, so that you can use overloaded literals, and then there's not much use for the constructor. Cheers, Simon

2 1

Changes in PostHooks
by Krasimir Angelov 09 Feb '05

09 Feb '05

I would like to do some checks in the cabalized HSQL during configure phase. In order to do this I need to know where GHC is installed. I decided to do this in the postConf hook but I have slightly changed Hooks API. The types of all post hooks are: Args -> LocalBuildInfo -> IO ExitCode It seems like no one is using post hooks at this time so I think that it is safe to do this change. Thoughts? Cheers, Krasimir

3 3

RE: bracketOnError, while, forever
by Simon Marlow 09 Feb '05

09 Feb '05

On 07 February 2005 12:51, Peter Simons wrote: > 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. I think we should have bracketOnError, but I don't think the name is that great. Any ideas for a better one? Cheers, Simon

2 1

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

08 Feb '05

On 03 February 2005 02:54, Ashley Yakeley wrote: > * 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> I don't think we should have a type for POSIX time. What does it buy you? POSIX time is a broken notion that shouldn't be visible in our library interface. Suppose we just have a TAI time type, plus various calendar types. What goes wrong? Well, you can't accurately convert some TAI times into calendar times and vice versa, in particular all times more than 6 months ahead of the leap second table. Too bad. You can still do accurate calculations on calendar times in the future, and that's what matters. The most common conversion between TAI & calendar time is going to be for the current time, and that will be correct as long as we have an up to date leap second table. Even if we don't have an up to date leap second table, we can still convert from system clock-->TAI-->calendar time, because the leap second calculations cancel out (for a POSIX system clock). > * 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. I don't think we need this either, at lesat not in the external interface. Any calculations you can do with this type you can do on a calendar time. Cheers, Simon

9 13

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