August 2009 - Libraries

Platform et al
by Don Stewart 08 Aug '09

08 Aug '09

http://joelrayking.wordpress.com/2009/08/08/starting-out-with-haskell/ "never thought I’d actually get this excited about learning a programming language again" Yay. This work pays off. -- Don

1 0

Containers in the Haskell Platform
by Alexander Dunlap 07 Aug '09

07 Aug '09

Hi all, As we consider what we want to go into the Haskell Platform, I would like to seriously discuss the issue of container polymorphism, especially, but not exclusively, in dealing with strings. We currently have a large number of container types, many of which are going to co-exist long-term, i.e. there is no winner; they are useful in different situations. Here is an incomplete list of what we are dealing with: Fully polymorphic sequence types: [] Data.Sequence Data.Edison sequence types Data.Array.Array & friends Restricted polymorphic sequence types: uvector vector storable-vector Monomorphic sequence types: ByteString (Word8 and Char8) Lazy ByteString (Word8 and Char8) Text Fully polymorphic associative array types: Data.Map Edison associative arrays gmap (?) Less-polymorphic associative array types: bytestring-tries list-tries Data.IntMap I'm sure there are more, of course, but those are the ones that a cursory search reveals. The question, then, is how we ought to deal with all of these types in the Haskell Platform. The current popular libraries deal with the multitude of container types in a very ad-hoc way. For instance, the Parsec parsing library allows you to parse Strings and Strict ByteStrings; it also includes a class so that you can parse other things. Attoparsec allows you to parse only lazy bytestrings. I don't know of any library that parses Text yet. The binary library deals with lazy bytestrings, while binary-strict lets you use strict bytestrings. Libraries like zlib just pick a type (lazy bytestrings) and use that, not accounting for other possible types you may want to use (granted, in zlib's case, the choice of a single data structure, seems fairly reasonable, given potential use cases). The point here is that the same functionality and practically the same code can be split over several different packages based on what data structure you want to use. Worse, there is no standard way of dealing with this separation: Parsec uses a type class, while binary uses two separate packages. And interoperability could potentially become a problem: the split library, for instance, only supports lists, so you have to roll your own solutions for splitting ByteStrings or Text. I think that with the introduction of the Haskell Platform, we ought to take the opportunity to clean up some of this chaos so that we have a clean set of standard libraries for people to build on. The way I see it, we have a few options. We could introduce some type classes to cover the various container operations and ask all Platform packages to only use operations from these classes, where applicable. (The ListLike library would probably be a good place to start.) The issue here is efficiency, massive class dictionaries, and type system issues (we need MPTCs or TFs; also, since not all sequence types are polymorphic, we probably need to have separate map and rigidMap functions like in ListLike, and even that doesn't work for types like uvector that can take some, but not all, concrete element types). We could also implement a standard module-naming scheme: for every package that operates on strings, for instance, we could require the list-based code to go in Foo.Bar.String and the Text code to go in Foo.Bar.Text. Whenever we "blessed" a new string datatype (presumably not very often), all packages would have to add a new module. The issue is code duplication. We could also implement a package naming scheme: have foo-text and foo-string for the two different datatypes. What does everyone think about the need for standardization here and how we ought to do it? I'm sorry that, having less experience with Haskell than many, I can't give as much in the way of concrete proposals, but I think it's important that we hash something out here to get more organization in our Platform. Thanks for your time in reading this admittedly long message, Alex

5 5

Adding binary to the Haskell Platform
by Don Stewart 07 Aug '09

07 Aug '09

Here's a ticket for Simon Marlow's proposal: http://trac.haskell.org/haskell-platform/ticket/86 Let's discuss, then have the steering committee recommend yay/nay. -- Don

15 27

Re: Thinking about what's missing in our library coverage
by Malcolm Wallace 07 Aug '09

07 Aug '09

> As a Haskell Platform user, I really need the assurance that the > licensing situation is straightforward - especially if I'm to promote > Haskell at work :-) > > My vote would be that non-BSD/MIT license automatically excludes a > library from inclusion, even though it would exclude my own project. I wonder if it would be possible to split the Haskell Platform into two parts, platform-BSD and platform-LGPL? The LGPL packages could depend on packages from platform-BSD, but not the other way around. This would guarantee at least one aspect of licence compliance, whilst also making it clear to proprietary users that if they want to avoid the guarantee of freedom, they can simply avoid installing platform- LGPL. Regards, Malcolm

8 27

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

06 Aug '09

Ross, fromList2 takes perhaps 3ms off the time when n=50000. (It is essentially a two-liner, so I consider this acceptable.) Nevertheless, I have slightly improved the performance of the stable heapsort; essentially, when labeling values with their index, the index is left as a lazy thunk, but the computation is organized so computing any index takes O(log n). The speed increase from fromList . Data.List.sort . toList is still but 40% of the speed increase from the heapsort. Again, I'd like to propose a compromise: make Data.Sequence.sortBy cmp be either fromList2 . Data.List.sortBy cmp . toList, or use the stable pairing-heap sort, and add a second sorting method, sortBy', that is unstable but faster. Times (ms) min mean +/-sd median max to/from list: 113.561 119.800 5.470 118.678 139.390 pairing heap: 62.440 67.032 3.861 65.174 80.499 stable pheap: 93.402 102.253 11.854 98.529 158.922 fromList2 . toList: 110.221 118.364 6.525 116.265 136.683 Louis Wasserman wasserman.louis(a)gmail.com

4 6

Hackage Download Rankings August 2009
by Don Stewart 05 Aug '09

05 Aug '09

Total package downloads on Hackage, by August 1 2009, http://www.galois.com/~dons/hackage/august-2009/popularity-august-2009.html All packages by month: http://www.galois.com/~dons/hackage/august-2009/hackage-august-2009.html Raw data: http://www.galois.com/~dons/hackage/august-2009/hackage-downloads-august-20… Enjoy. -- Don P.S. For reference, here's the data from March, http://www.galois.com/~dons/hackage/popularity.html and analysis at the time http://www.galois.com/blog/2009/03/23/one-million-haskell-downloads/

3 3

Discussion period
by Don Stewart 04 Aug '09

04 Aug '09

The Haskell Platform follows the GNOME strategy for releases, with a release cycle and freeze date. We're now in the open package proposal and discussion period, which will close N weeks before the next freeze. I'm not sure what N should be. -- Don

2 1

HOWTO: Propose a package be added to the Haskell Platform
by Don Stewart 04 Aug '09

04 Aug '09

To propose a package be added to the Haskell Platform: http://trac.haskell.org/haskell-platform/wiki/WikiStart * Click on "Propose adding a new package" * Fill out the heuristics/background as best as you can -- Don

1 0

Re: Thinking about what's missing in our library coverage
by John Lato 04 Aug '09

04 Aug '09

> Date: Tue, 4 Aug 2009 15:13:16 +0100 > From: "Jeremy O'Donoghue" <jeremy.odonoghue(a)gmail.com> > > My vote would be that non-BSD/MIT license automatically excludes a > library from inclusion, even though it would exclude my own project. > +1 John Lato

1 0

PROPOSAL: Remove Control.OldException
by Ian Lynagh 04 Aug '09

04 Aug '09

Hi all, Proposal: Remove Control.OldException http://hackage.haskell.org/trac/ghc/ticket/3381 We included Control.OldException in base to help people trying to remain compatible with both GHC 6.8 and GHC 6.10. However, my impression is that most (all?) people who wanted compatibility used the extensible-exceptions package instead. I propose that we remove Control.OldException for GHC 6.12. If anyone does want Control.OldException, then it could be provided by a separate package. Deadline: 2nd August (2 weeks). Thanks Ian

9 13