August 2010 - Libraries

Proposal #3339: Add (+>) as a synonym for mappend
by Bryan O'Sullivan 08 Nov '11

08 Nov '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/3339 >From the ticket: This proposal was, I think, originally suggested by Jules Bean. The idea is to add two functions to the Data.Monoid module, (+>) and (<+), corresponding to different uses of mappend. These should not be methods of the Monoidtypeclass, but top-level functions. I hope (but slightly doubt) that the visual nature of the two operators might help to counter the thought that monoids are just for gluing things together. (+>) :: (Monoid a) => a -> a -> a a +> b = a `mappend` b (<+) :: (Monoid a) => a -> a -> a a <+ b = b `mappend` a infixl 4 +> infixl 4 <+ Proposed deadline: two weeks. If this looks reasonable, I'll attach darcs patches.

30 75

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

[darcs patch] filepath: normalise trailing dot
by Conrad Parker 21 Dec '10

21 Dec '10

Hi, the attached darcs patch modifies the behaviour of normalise to handle trailing dots in a path. The previous behaviour yielded this: Prelude System.FilePath> normalise "../." "../." Prelude System.FilePath> normalise ".././" ".././" Prelude System.FilePath> normalise ".././.." "../.." This patch modifies dropDots such that the check for (".":[]) only occurs once for the path, after which a driver function dropDots' is used which skips this check. Hence "." can be removed from the end of a longer path, but a path of just "." is unchanged. (my trac account is pending verification, I'll reply with a trac ticket # later if needed) cheers, Conrad.

4 7

Proposal: Performance improvements for Data.IntMap
by Don Stewart 23 Sep '10

23 Sep '10

#4279: Proposal: Performance improvements for Data.IntMap http://hackage.haskell.org/trac/ghc/ticket/4279 Following on from ticket #4277 here is a similar patch for Data.IntMap. This proposal provides a patch that improves performance for many parts of the API. Two standard techniques are applied to the code: * worker/wrapper transformations of functions with multiple static arguments * inlining of non-recursive wrappers Three complementary, but orthogonal patches are provided. 1. Add a testsuite, with [http://code.haskell.org/~dons/tests/containers/intmap/hpc_index.html coverage data] (currently 82% of top level functions, and all core functions). 2. Add a micro-benchmark suite based on Criterion, for empirical evidence of improvements to each function. 3. The optimization patch itself. All 3 patches should be applied, under this proposal. The [http://is.gd/eN7qN benchmark results] are relatively clear: * 13.3% faster on i7 / x86_64 / Linux * 9.95% faster on Mac OS X 10.5 / Xeon / 32 bit http://i.imgur.com/RJ7dH.png No bugs were identified in the development of the comprehensive testsuite, which includes a large set of unit tests from Kazu Yamamoto. ''Discussion'' Unlike Data.Map (#4277) the performance results are less significant for Data.IntMap. There is one main reasons: * Data.IntMap already has strict keys So the strict key improvements seen there are less impressive here. Similarly, worker/wrapper to float out a single Int key has less of an impact than floating out more complex structures used as keys. Hence, a number of functions are unchanged (modulo inlining), including lookup and delete. insert is slightly improved (due to inlining). ------------ A fork of the containers package, with the 3 patches (and a version bump to make it easier to test out) is available: darcs get http://code.haskell.org/~dons/code/containers/ Separately, the patches are attached to this ticket. The consideration period is 3 weeks (before ICFP). Work carried out over 28/29th August, 2010 in Utrecht, NL, by Johan Tibell

6 6

Proposal: Add function to create new hash tables with a default size
by Jim Apple 18 Sep '10

18 Sep '10

In other some standard libraries (Java, OCaml), hash tables can be created with a user-supplied size. This avoids some resizing for users who know they will be inserting a lot of data. Data.HashTable does not expose a function to do this. This proposal changes that. For a dictionary of 5 million strings, this patch saves me about 33% of the total execution time. For 10 million strings, this patch saves me 50% of the total execution time. http://hackage.haskell.org/trac/ghc/ticket/4193

4 6

Proposal: Significant performance improvements for Data.Map
by Don Stewart 12 Sep '10

12 Sep '10

http://hackage.haskell.org/trac/ghc/ticket/4277 Proposal: Significant performance improvements for Data.Map Description Milan Straka's recent [52] Haskell Symposium paper (PDF) shed light on the containers:Data.Map library, indicating there were both algorithmic and stylistic performance improvements to be made. 52. http://research.microsoft.com/~simonpj/papers/containers/containers.pdf This proposal provides a patch that [53] dramatically improves performance across the API. Three standard techniques are applied to the code: * [54] Worker/Wrapper transformations of recursive functions with constant arguments (aka. the [55] static argument transformation). * Explicit inlining of wrapper functions. * Explicit strictness of keys to functions. 53. http://is.gd/eJHIE 54. http://www.workerwrapper.com/ 55. http://hackage.haskell.org/trac/ghc/ticket/888 Three complementary, but orthogonal patches are provided. 1. Add a testsuite, [56] with coverage data (currently 91% of top level functions, and all core functions). 2. Add a micro-benchmark suite based on [57] Criterion, for empirical evidence of improvements to each function. 3. The optimization patch itself. All 3 patches should be applied, under this proposal. 56. http://code.haskell.org/~dons/tests/containers/hpc_index.html 57. http://hackage.haskell.org/package/criterion The [58] benchmark results are very strong: * An average speedup across the core api of 47% (on intel i7 / linux 64 bit), and; * 36% on Mac / intel core 2 duo 32 bit). http://i.imgur.com/05BWe.png 58. http://is.gd/eJHIE No bugs were identified in the development of the comprehensive testsuite, which includes a large set of unit tests from [60] Kazu Yamamoto 60. http://twitter.com/kazu_yamamoto/status/22351727559 A fork of the containers package, with the 3 patches (and a version bump to make it easier to test out) is available: darcs get http://code.haskell.org/~dons/code/containers/ Separately, the patches are attached to this ticket. The consideration period is 3 weeks (before ICFP). __________________________________________________________________ Work carried out over 28/29th August, 2010 in Utrecht, NL, by Johan Tibell and Don Stewart.

6 10

ANNOUNCE: iteratee-parsec 0.0.4
by Maciej Piechotka 06 Sep '10

06 Sep '10

Iteratee-parsec is a library which allows to have a parsec (3) parser in Iteratee monad. It contains 2 implementations: - John Lato's on public domain. It is based on monoid and design with short parsers in mind. - Mine on MIT. It is based on single-linked mutable list. It seems to be significantly faster for larger parsers - at least in some cases - but it requires a monad with references (such as for example IO or ST). The version 0.0.4 is ported to iteratee 0.4. Regards

3 4

Crypto-API is stabilizing
by Thomas DuBuisson 05 Sep '10

05 Sep '10

All, Crypto-API - a unified interface to which I hope hash and cipher algorithms will adhere - has recently gotten a reasonable amount of polish work. I continue to welcome all comments! A blog on its current interface is online [1] as are darcs repositories of the crypto-api package [2]. Recent changes includes added block cipher modes, platform-independent RNG, tests, a simplistic benchmark framework, and minor tweaks of the classes. I've made experimental hash, block cipher and stream cipher instances. Almost no optimizations have been made as of yet! Thanks to everyone for their past comments! I have made numerous changes based on input received. If you feel I didn't respond properly to your suggestion then please ping me again - this is purely a spare time effort and things do fall through the cracks. Cheers, Thomas [1] http://tommd.wordpress.com/2010/08/23/a-haskell-api-for-cryptographic-algor… [2] http://community.haskell.org/~tommd/crypto/ (If you're wondering why you're BCCed its probably because you worked on a crypto-related Haskell package)

2 5

Proposal: Performance improvements for Data.Set
by Johan Tibell 03 Sep '10

03 Sep '10

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4280 Proposal: Performance improvements for Data.Set Following on from ticket #4277 here is a similar patch for Data.Set. This proposal provides a patch that improves performance for many parts of the API. Three standard techniques are applied to the code: * Worker/Wrapper transformations of recursive functions with constant arguments (aka. the static argument transformation). * Explicit inlining of wrapper functions. * Explicit strictness of keys to functions. Three complementary, but orthogonal patches are provided. * Add a testsuite, with coverage data (currently 51% of top level functions, and all core functions). * Add a micro-benchmark suite based on Criterion, for empirical evidence of improvements to each function. * The optimization patch itself. All 3 patches should be applied, under this proposal. The benchmark results are relatively clear: 32% faster on OS X 10.5.8 on 2 GHz Core 2 Duo The consideration period is 3 weeks (before ICFP). Work carried out over 28/29th August, 2010 in Utrecht, NL, by Johan Tibell and Don Stewart.

3 3

Proposal: Add strict versions of foldlWithKey and insertLookupWithKey to Data.Map
by Johan Tibell 03 Sep '10

03 Sep '10

http://hackage.haskell.org/trac/ghc/ticket/4278 Proposal: Add strict versions of foldlWithKey and insertLookupWithKey to Data.Map This proposal depends on #4277 [1]. The current Data.Map API lacks two important functions: * A strict left (pre-order) fold -- needed to e.g. sum all the values in a map efficiently. * A strict insertLookupWithKey' -- needed to e.g. update an integer counter and retrieve the previous value in a single traversal. The benchmark we ran indicates that foldlWithKey' is 95% faster than its lazy counter part.insertLookupWithKey' is only 6% faster, but the speedup is highly dependent on how many times each element is update. Each element was only updated once in our benchmark so real speedups should be larger. The consideration period is 3 weeks. 1. http://hackage.haskell.org/trac/ghc/ticket/4277

4 5