July 2009 - Libraries

Volunteers for a Haskell Platform steering committee
by Duncan Coutts 20 Jul '09

20 Jul '09

All, We recently discussed on the libraries list the issue of major vs minor releases, their frequency and what should be included in each. http://trac.haskell.org/haskell-platform/wiki/Policy There are a number of other policy decisions about the Haskell Platform that we will need to make in the coming weeks and months. The platform is supposed to be owned by and serve the interests of the community. As such it is important that significant decisions have some kind of community backing. The intention is that important issues are brought to the libraries mailing list, debated there and decisions reached. To ensure that the relevant issues are indeed discussed and decisions get made, we are proposing a steering committee. It would be the job of the steering committee to see that the important issues are properly discussed and decisions are made and recorded. It would be up to the committee to decide what issues to present, how to start discussions and if necessary how to guide them. Here are some examples of issues that the steering committee will likely want to bring to the attention of this mailing list: * general package quality requirements * portability (OS and compiler/language) * balance of quality vs quantity in libraries * license requirements * procedures for deciding which packages to add (or drop) It is not the intention that the committee members get much more say in policy decisions than other active contributors to discussion on the libraries mailing list. We hope therefore that the membership of the committee does not need to be terribly formal. The only difficulty comes when consensus cannot be reached on an issue where making some decision is widely agreed to be better than making no decision. There is no specified protocol for this situation at this stage. There would obviously have to be good communication between the steering committee and the platform release team. The needs of the release team will inform the issues that get discussed and obviously the libraries list cannot mandate that the release team do the impractical. We are now seeking volunteers for this steering committee. A good number is probably around five. Comments, criticisms and volunteers please! Duncan PS. I'm going to be away 'til Sunday.

4 3

Volunteers for a Haskell Platform steering committee
by Thomas Schilling 19 Jul '09

19 Jul '09

Wrong reply button. ---------- Forwarded message ---------- From: Thomas Schilling <nominolo(a)googlemail.com> Date: 2009/7/20 Subject: Re: Volunteers for a Haskell Platform steering committee To: Johan Tibell <johan.tibell(a)gmail.com> Ah, why not. Consider my hand voluntarily raised. 2009/7/15 Johan Tibell <johan.tibell(a)gmail.com>: > On Wed, Jul 15, 2009 at 7:04 PM, Isaac Dupree > <ml(a)isaac.cedarswampstudios.org> wrote: >> >> Duncan Coutts wrote: >>> >>> We are now seeking volunteers for this steering committee. A good number >>> is probably around five. >>> >>> Comments, criticisms and volunteers please! >> >> sounds acceptable. A commitment not to let the issue drop (It seems >> especially important to create such a commitment to get us through the first >> year of doing HP). I'll volunteer... > > I volunteer too. > > -- Johan > > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > -- Push the envelope. Watch it bend. -- Push the envelope. Watch it bend.

1 0

Re: Proposal #3271: new methods for Data.Sequence
by Louis Wasserman 18 Jul '09

18 Jul '09

In response to Ross's useful suggestions (which I had not actually noticed until recently), I have made considerable changes to my Data.Sequence patch here<http://hackage.haskell.org/trac/ghc/attachment/ticket/3271/new-methods-for-…> . Here are the relevant points: - I completely rewrote the sorting method. The sort is unstable, but it is 40 lines (much more maintainable than the several-hundred line implementation from earlier) and runs *twice as fast as* (fromList . Data.List.sort . toList) for n=50000. (For sorted lists, it clocks in at about 4x faster.) - tails and inits are considerably more sophisticated, running to about 50 lines apiece (although some of that code is shared between them), but - This implementation is genuinely asymptotically faster than the previous implementation: evaluating any tail from the sequence returned by tails takes O(log (min (i, n-i))), as opposed to O(n) in scanr (<|) empty xs, but evaluating every tail from the sequence takes O(n) overall, as opposed to O(n log n) in fromList [drop n xs | n <- [0..length xs]]. - Without direct access to the internals of the sequence it is impossible to match the asymptotic performance of this implementation. - This implementation is also a hair faster in practice. - partition is now in fact implemented via a simple foldl', which is actually faster than my old, several-dozen-line implementation as well as obviously simpler. - filter has been added to the list of methods available in Data.Sequence. - iterate has been renamed to iterateN to reinforce the different type, which requires a finite bound on the sequence length. - On the back end, replicate, iterateN, and sortBy do not use fromList, but instead use a common framework that wraps construction of a sequence in an Applicative functor. This automatically induces the node sharing that gives replicate performance O(log n), but behaves exactly correctly for all its other requirements. - As a result, there is a faster alternative to fromList if the length of the list is known. The name and type of this method seems like it might become genuinely contentious, so I'm not inclined to expose that faster method at the moment. Louis Wasserman wasserman.louis(a)gmail.com

3 2

random tune
by Laszlo Nagy 18 Jul '09

18 Jul '09

Hi All, I would like to contribute something useful for the community. I've read through some tickets and found I can't solve any of them. Instead I've looked for small tasks which might help to complete one. One was the #1338 ticket, which mention that random package should use 'time' package instead of 'old-time'. I also run the hlint program against the random library and applied the recommendations. Here are the patches: http://sites.google.com/site/rizsotto/patches/random-time.darcs http://sites.google.com/site/rizsotto/patches/random-hlintclean.darcs Regards, Laszlo

3 3

Re: Proposal #3271: new methods for Data.Sequence
by Louis Wasserman 17 Jul '09

17 Jul '09

The faster sort for Data.Sequence is a heapsort based on a pairing heap implementation. The only way I can think of to make it stable is to index the entire sequence and then add indices to the comparisons, which removes almost all of the benefit of the heapsort implementation: Times (ms) min mean +/-sd median max to/from list: 106.742 111.269 4.831 110.207 138.638 pairing heap: 62.896 66.066 2.410 65.433 74.471 stable pheap: 95.600 102.381 5.807 100.744 120.395 Even worse, the stable heapsort becomes genuinely worse when there's memory to spare; with +RTS -H128m: Times (ms) min mean +/-sd median max to/from list: 53.675 84.407 14.130 86.319 108.553 pairing heap: 62.492 77.065 9.649 78.883 104.606 stable pheap: 70.437 97.718 15.332 100.548 134.624 Perhaps the most reasonable compromise would be to include the faster sort method, but name it sortBy' or something else indicating that it is nonstandard. (That still leaves open the question of whether the stable sort method should be the Data.List conversion, or the stable heapsort.) I had forgotten to mention that zipWith had been modified to a one-liner with mapAccumL, which actually proved faster than my implementation. Louis Wasserman wasserman.louis(a)gmail.com

1 0

cabal: : openFile: does not exist (No such file or directory)
by Tony Hannan 17 Jul '09

17 Jul '09

Hello, I'm on Ubuntu 8.10. I installed ghc 6.10.4 (from binary package: ghc-6.10.4-i386-unknown-linux-n.tar.bz2). I installed haskell-platform-2009.2.0.1 (from source package: haskell-platform-2009.2.0.1.tar.gz). It contains cabal-install-0.6.2. Then when I run "cabal update", I get the following error: cabal: : openFile: does not exist (No such file or directory) Any ideas? Thanks, Tony

2 1

Proposal #3337: expose Unicode and newline translation from System.IO
by Simon Marlow 14 Jul '09

14 Jul '09

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3337 For the proposed new additions, see: * http://www.haskell.org/~simonmar/base/System-IO.html#23 System.IO (Unicode encoding/decoding) * http://www.haskell.org/~simonmar/base/System-IO.html#25 System.IO (Newline conversion) Discussion period: 2 weeks (14 July).

5 9

Re: Adding a newtype EndoCategory to Control.Category (ticket #3362)
by roconnor＠theorem.ca 13 Jul '09

13 Jul '09

>> Oh, that is a quite a downside. I wonder if we can get cabal stats on >> this without difficulty. > > The only packages on hackage containing instances for Endo are: > > base > HStringTemplate > monoids > special-functors > TypeCompose Is this few enough that we can make our change? -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

5 6

PROPOSAL: Put DiffArray in its own diffarray package
by Ian Lynagh 11 Jul '09

11 Jul '09

Hi all, Proposal: Put DiffArray in its own diffarray package http://hackage.haskell.org/trac/ghc/ticket/3370 DiffArray currently has serious performance problems; see http://hackage.haskell.org/trac/ghc/ticket/2727 and is not currently being actively maintained. However, as part of the corelib array it gives the impression that it is a "blessed" library. I propose that we split DiffArray off into its own diffarray package. This also has the advantage that it can then be maintained by a separate maintainer, if someone is interested, and it will be decoupled from GHC's major release schedule. Deadline: 26 July (2 weeks). Thanks Ian

4 3

Bug in old-locale?
by Deniz Dogan 11 Jul '09

11 Jul '09

Hi Is there a bug in the old-locale package? I tried the following simple program: import Data.Time import System.Locale main = do time <- getCurrentTime putStrLn $ formatTime defaultTimeLocale rfc822DateFormat time The above program prints: Mon, d Apr 2009 15:23:56 UTC Notice "Mon, d", where "d" should be the day of the month. Looking at the source code in the package, I see: rfc822DateFormat = "%a, %_d %b %Y %H:%M:%S %Z" So what's up with %_d? -- Deniz Dogan

4 6