February 2005 - Libraries

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

10 Feb '05

On 10 February 2005 16:18, Ross Paterson wrote: > On Thu, Feb 10, 2005 at 03:33:48PM -0000, Simon Marlow wrote: >> 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. > > There's a dissonance between the need to ship GHC and the unfinished > state of Cabal. Most of the interface is worked out, but there are a > few parts (not the parts currently used by GHC) that are experimental > and/or need fixing, and these have had very little user feedback. I > think this will be a beta release for Cabal, and its interface will > need changing soon. What to do? Independent releases of Cabal > updates? It's certainly possible to produce an updated version of Cabal later on, released independently of GHC. However, that's a bit of a pain - if there are only a few minor interface changes to go in, I'm prepared to hold the GHC release until they're finished. Cheers, Simon

2 1

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

10 Feb '05

On 08 February 2005 12:33, Thomas Jäger wrote: > First of all >> -- Cale Gibbard >> comparing :: (Ord a) => (b -> a) -> b -> b -> Ordering >> comparing p x y = compare (p x) (p y) > fits nicely with the ...By functions from Data.List. sortBy (comparing fst) is just too cute not to have. Any objections? > Since there's no easy way to catch failure of read operations, >> readM :: (Monad m, Read a) => String -> m a >> readM s = case [x | (x,t) <- reads s, ("","") <- lex t] of >> [x] -> return x >> [] -> fail "Prelude.readM: no parse" >> _ -> fail "Prelude.readM: ambiguous parse" > this function seems to be quite natural. Also subsumes System.IO.readIO. Looks useful to me. > Finally, >> -- Koen Claessen >> selections :: [a] -> [(a,[a])] >> selections [] = [] >> selections (x:xs) = (x,xs) : [ (y,x:ys) | (y,ys) <- selections xs ] >> >> permutations :: [a] -> [[a]] >> permutations [] = [[]] >> permutations xs = >> [ y : zs >> | (y,ys) <- selections xs >> , zs <- permutations ys >> ] > are quite useful (maybe they should be named select and permute since > most Data.List names seem to be imperatives). Both look reasonable. Not all the names in Data.List are imperative (eg. inits, tails, lines, words). I think the names are fine. Cheers, Simon

7 10

Cabal package descriptions
by Ross Paterson 10 Feb '05

10 Feb '05

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.

2 3

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