- Libraries - Haskell.org

RE: Cabal package descriptions
by Simon Marlow 10 Feb '05

10 Feb '05

On 10 February 2005 12:54, Ross Paterson wrote: > I think we need an extra field Synopsis for a short summary of the > package, possibly supplemented by the longer Description. This should > make Hackage catalogues more readable, and could also be shown by an > extended form of hc-pkg list. > > (repeated) License and License-File should not be mutually exclusive. > They're both useful, for different purposes. Perhaps License would > be more accurately called License-Type. > > Perhaps Hidden-Modules should be renamed Other-Modules, now that it > is used by both libraries and executables. I more or less agree with all this, but it's too late to get any API changes into 6.4 now. We might have to start thinking about backwards compatibility. Cheers, Simon

2 1

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

10 Feb '05

On 10 February 2005 10:15, Ashley Yakeley wrote: > In article > <3429668D0E777A499EE74A7952C382D103238B8A(a)EUR-MSG-01.europe.corp.microso > ft.com>, > "Simon Marlow" <simonmar(a)microsoft.com> wrote: > >>> 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. > > Do you mean for DiffTime or for JulianDay? Maybe JulianDay should be an Integral type too. Of the three choices: (a) type synonym for Integer (b) non-abstract newtype (c) abstract newtype (a) and (c) are both better than (b). (c) is better than (a) in the sense that you can use different instances for existing classes: eg. we can have a specialised instance of Show for JulianDay, if we want. So, I'd go for abstract newtypes consistently. Cheers, Simon

1 0

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

10 Feb '05

On 10 February 2005 11:14, Ketil Malde wrote: >> * getting the current "CPU time" > > Isn't this very system dependent? And isn't times(2) a better choice > than clock(3)? How do these behave in the presence of leap seconds? > I.e. if I clock() a computation, do I get the same result as > the difference of gettimeofday()s before and after times CPU > utilization, or do I get the correct times, and the consequential a > leap-second offset compared to gettimeofday? > > I'm not able to find any information on this; I assume these functions > deal in (non-linear) POSIX time, since you want them in the same > module? > > (I would put everyting to do with performance meausrements in a > different module. Although, I guess if we only target POSIX systems, > this is all right. The consensus seems to be to wed time to POSIX.) There is already System.CPUTime, BTW. Ashley: are you proposing to replace this? Simon

2 1

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