November 2011 - Libraries

Implement foldMap on Data.Sequence.Seq?
by Sjoerd Visscher 05 Nov '11

05 Nov '11

When experimenting with the code here: http://stackoverflow.com/questions/7869359/why-is-it-faster-to-sum-a-data-s… it turned out that foldMapDefault from traversable was more than 2x faster than foldl', and more than 6x faster than foldMap. foldMap is not implemented by Data.Seq, so it defaults to foldr (mappend . f) mempty. Does anybody have a good explanation for the StackOverflow question, and would it be a good idea to add a foldMap implementation to Seq? greetings, Sjoerd Visscher

1 0

RFC: Should Data.IntMap.Strict be value-strict in the function arguments or the map itself
by Johan Tibell 04 Nov '11

04 Nov '11

Hi all, As discussed in an earlier (accepted) proposal we're adding Data.[Int]Map.{Strict,Lazy} APIs to make it easier for users to get the desired strictness. There are two subtly different ways these APIs can be strict: 1. All the functions are strict in the value argument, or 2. The structure is strict in the value field. The difference shows up in functions like insertWith. For example, given insertWith (\ old _new -> old + 1) k v someMap should 'v' be evaluated is the key 'k' is already in the map. (Note that the value isn't used in the update function.) If we go with option 2 it is more difficult for the user to reason about if a given value passed to the API is evaluated or not (as in the above example). We currently use option 1 for keys i.e. insert k v someMap is strict in the key even if the map is empty (which wouldn't require us to look at the key). Thoughts? I'd love to see some design pros/cons of both approaches. -- Johan

6 17

Proposal: Add NFData instances for strict and lazy ByteStrings
by Bas van Dijk 04 Nov '11

04 Nov '11

While I was hunting for a space leak in the new hackage-server (still haven't found it) I noticed strict and lazy ByteStrings don't have NFData instances. I propose to add them because it enables users to force ByteStrings in the principled way (using deepseq) so they don't need to use tricks like: B.length b `seq` ... instance NFData Strict.ByteString instance NFData Lazy.ByteString where rnf Empty = () rnf (Chunk _ b) = rnf b Note that the containers dependency of deepseq was recently dropped so depending on that package is not a big issue anymore. Discussion deadline: 2 weeks from now (9 November) Bas

9 10

Proposal: Remove Show and Eq superclasses of Num
by Ian Lynagh 04 Nov '11

04 Nov '11

Hi all, I would like to propose that we remove the Show and Eq superclasses from Num, i.e. change class (Eq a, Show a) => Num a where [...] to class Num a where [...] The first 2 attached patches (for base and ghc respectively) remove the Show constraint. I'm not aware of any justification for why this superclass makes sense. The next 2 patches (for base and unix respectively) remove the Eq constraint. Here's there's some justification in the superclass, as it makes f 5 = ... work for any Num type, rather than also needing an Eq constraint, but personally I would be in favour of removing this superclass too. Noteworthy is that Bits now needs an Eq superclass for the default methods for 'testBit' and 'popCount'. The fifth patch (for base) is what prompted me to get around to sending this proposal. It lets us de-orphan the Show Integer instance. Any opinions? Suggested discussion deadline: 12th October Thanks Ian

21 50