October 2011 - 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

Proposal: Add {to,from}Strict conversion functions between strict and lazy ByteStrings
by Herbert Valerio Riedel 07 Nov '11

07 Nov '11

I propose to add optimized {to,from}Strict conversion functions between strict and lazy ByteStrings to the Data.ByteString.Lazy API. Discussion deadline: 2 weeks from now (12 November) = Current State = The current Data.ByteString.Lazy API doesn't provide direct conversion functions to/from single strict ByteStrings Currently, there are only `fromChunks` and `toChunks`, by which convert to/from a list of strict ByteStrings. A possible reference implementation of the missing conversion functions is: fromStrict = BL.fromChunks . (:[]) and toStrict = B.concat . BL.toChunks == The Issues == The lack of `fromStrict`/`toStrict` in the Data.ByteString.Lazy API has the following issues: - Convenience: If the single-strict-bytestring conversion is often needed, one tends to define module- or package-local helper functions for convenience/readability to perform the desired conversion. This violates the DRY principle. - Principle of least suprise: Might be confusing to users new to `Data.ByteString.Lazy` why there is no direct conversion. - Symmetry with `Data.Text.Lazy` API which does provide such single-strict-text conversion functions (`fromStrict`/`toStrict`) - Performance: The above provided "naive" `toStrict` definition has a roughly 2 to 4 times higher overhead than a manually fused version (which was kindly provided by Bas van Dijk -- whom I'd like to thank for providing me with the optimized versions of toStrict and fromStrict) -- see end of this mail for criterion benchmark code and results = Proposed Enhancement = Enhance the Data.ByteString.Lazy API by adding the following conversion functions (suggestions for improvements are highly welcome): -- see benchmark code at end of mail for the qualified imports -- |/O(n)/ Convert a strict ByteString into a lazy ByteString. fromStrict :: B.ByteString -> BL.ByteString fromStrict = flip BLI.chunk BLI.Empty -- |/O(n)/ Convert a lazy ByteString into a strict ByteString. toStrict :: BL.ByteString -> B.ByteString toStrict lb = BI.unsafeCreate len $ go lb where len = BLI.foldlChunks (\l sb -> l + B.length sb) 0 lb go BLI.Empty _ = return () go (BLI.Chunk (BI.PS fp s l) r) ptr = withForeignPtr fp $ \p -> do BI.memcpy ptr (p `plusPtr` s) (fromIntegral l) go r (ptr `plusPtr` l) == Benchmark Code & Results == ------------------------------------------------------------------------ {-# LANGUAGE OverloadedStrings #-} import Criterion import Criterion.Main import qualified Data.ByteString as B import qualified Data.ByteString.Internal as BI import qualified Data.ByteString.Lazy as BL import qualified Data.ByteString.Lazy.Internal as BLI import Foreign.ForeignPtr import Foreign.Ptr toStrict1 :: BL.ByteString -> B.ByteString toStrict1 = B.concat . BL.toChunks toStrict2 :: BL.ByteString -> B.ByteString toStrict2 lb = BI.unsafeCreate len $ go lb where len = BLI.foldlChunks (\l sb -> l + B.length sb) 0 lb go BLI.Empty _ = return () go (BLI.Chunk (BI.PS fp s l) r) ptr = withForeignPtr fp $ \p -> do BI.memcpy ptr (p `plusPtr` s) (fromIntegral l) go r (ptr `plusPtr` l) main :: IO () main = do let lbs1 = "abcdefghij" lbs2 = BL.fromChunks (replicate 10 "abcdefghij") lbs3 = BL.fromChunks (replicate 1000 "abcdefghij") -- force evaluation of lbs{1,2,3} and verify validity print $ toStrict1 lbs1 == toStrict2 lbs1 print $ toStrict1 lbs2 == toStrict2 lbs2 print $ toStrict1 lbs3 == toStrict2 lbs3 defaultMain [ bgroup "toStrict" [ bench "simple #1" $ whnf toStrict1 lbs1 , bench "simple #2" $ whnf toStrict1 lbs2 , bench "simple #3" $ whnf toStrict1 lbs3 , bench "optimized #1" $ whnf toStrict2 lbs1 , bench "optimized #2" $ whnf toStrict2 lbs2 , bench "optimized #3" $ whnf toStrict2 lbs3 ] ] {- True True True warming up estimating clock resolution... mean is 2.302557 us (320001 iterations) found 2039 outliers among 319999 samples (0.6%) 1658 (0.5%) high severe estimating cost of a clock call... mean is 54.99870 ns (14 iterations) found 1 outliers among 14 samples (7.1%) 1 (7.1%) low mild benchmarking toStrict/simple #1 mean: 28.96077 ns, lb 28.89527 ns, ub 29.01562 ns, ci 0.950 std dev: 305.8466 ps, lb 262.1008 ps, ub 345.6136 ps, ci 0.950 benchmarking toStrict/simple #2 mean: 487.0739 ns, lb 486.7939 ns, ub 487.4713 ns, ci 0.950 std dev: 1.699232 ns, lb 1.262363 ns, ub 2.457099 ns, ci 0.950 benchmarking toStrict/simple #3 mean: 55.06322 us, lb 54.91370 us, ub 55.20236 us, ci 0.950 std dev: 741.6239 ns, lb 656.3273 ns, ub 846.6403 ns, ci 0.950 benchmarking toStrict/optimized #1 mean: 48.67522 ns, lb 48.65188 ns, ub 48.70237 ns, ci 0.950 std dev: 129.3192 ps, lb 111.3761 ps, ub 165.4819 ps, ci 0.950 benchmarking toStrict/optimized #2 mean: 178.6342 ns, lb 178.5480 ns, ub 178.7276 ns, ci 0.950 std dev: 457.4436 ps, lb 409.2746 ps, ub 519.8267 ps, ci 0.950 benchmarking toStrict/optimized #3 mean: 13.01866 us, lb 13.00734 us, ub 13.03549 us, ci 0.950 std dev: 70.09916 ns, lb 52.18012 ns, ub 97.77226 ns, ci 0.950 -}

14 16

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

Non-controversial rewrite RULES for time package
by Liyang HU 31 Oct '11

31 Oct '11

Hi, The time package is too slow. :( A prime example is diffUTCTime, which invokes utcTimeToPOSIXSeconds, which in turn calls realToFrac :: DiffTime -> NominalDiffTime. The former of these two types notionally accounts for leap seconds, while the latter does not. Both are newtypes around Data.Fixed.Pico. Since realToFrac is used in the library only when we know the difference is within one day, the two notions coincide, and there is no need to account for leap seconds. Indeed it currently (or rather, its implementation of "fromRational . toRational") behaves as such. I propose we include some rewrite RULES to eliminate the round-trip via Rational. For the attached benchmark, I get a ~4x improvement in speed. Discussion period: 2 weeks. Cheers, /Liyang

3 2

Proposal: Remove Num superclass of Bits
by Bas van Dijk 29 Oct '11

29 Oct '11

On 15 October 2011 00:01, Ian Lynagh <igloo(a)earth.li> wrote: > Removing the Num superclass of Bits was also mentioned, but that would > need its own proposal. Ok, I would like to propose removing the Num superclass of Bits. This would, for example, enable Vectors to get an instance for Bits: http://trac.haskell.org/vector/ticket/59 Discussion period: the usual 2 weeks (29 Oct.) Regards, Bas

14 37

Hackage rejecting packages
by Iavor Diatchki 28 Oct '11

28 Oct '11

Hello, I just noticed that the public Hackage server has started refusing to accept packages that do not have an upper bound on "base". I think that this crosses the line of useful static checking and, instead of helping package maintainers, it creates more work for them. (A warning to the same effect would be just fine.) Why do I think that? Choosing a conservative upper bound for the 'base' dependency of a library does not really lead to more stable builds---while it ensures that your library will build correctly, it tends to cause failures in the building of applications that use your library (because there is no set of packages that satisfies the combined dependencies). This is particularly true for the case of "base" because all packages depend on it. So placing a conservative constraint automatically makes your library incompatible with any package that might use a feature that was introduced after the constraint. While, in principle, "base" could completely change in the future, in practice there is a fairly large set of functions that are quite stable and it is not hard to write fairly future proof code. I think that it should be up to the maintainer to decide if they have an upper bound or not, just like with any other package. -Iavor

4 3

Proposal: Warn about ArrowLoop instance for Kleisli Arrows
by Heinrich Apfelmus 26 Oct '11

26 Oct '11

Hello, I recently noticed that the instance MonadFix m => ArrowLoop (Kleisli m) does not fulfill the ArrowLoop laws for most monads, rendering it either useless or dangerous for the unwary. Removing it would be the correct thing to do, but I think that the sensible thing to do is to merely document said fact at the instance declaration in the haddocks. This way, the few monads that do support an ArrowLoop instance (most notably the lazy state monad) can keep their instance while everyone else is warned. Thus, I suggest to add documentation to the instances, along the lines of "Even though every monad that supports 'mfix' can be made an instance of 'ArrowLoop', it usually /does not/ fulfill all of the corresponding ArrowLoop laws. Use this instance at your own risk." The main problem is the right-tightening law loop (first h <<< f) = h <<< loop f which fails for most monads. Consider the following example: bad :: String -> IO () bad = runKleisli $ loop (first (Kleisli putStrLn) <<< arr swap) where swap (a,b) = (b,a) Using the ArrowLoop laws [1], this example should be equal to ... = runKleisli $ Kleisli putStrLn <<< loop (arr swap) = putStrLn However, trying the example in GHCi will throw "Exception: <<loop>>", which clearly shows that this equality is not true. The underlying reason is that MonadFix doesn't support a corresponding right-tightening law, just as mentioned for example in [2]. [1]: http://www.soi.city.ac.uk/~ross/papers/fop.html [2]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.5172 Discussion period: 2 weeks (ends 24 October 2011) Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com

5 8

Proposal: Add default instances for Functor and Applicative
by Maciej Marcin Piechotka 23 Oct '11

23 Oct '11

The problem of backward compatibility have been the main obstacle against adopting Functor f => (Pointed f =>?) => Applicative f => Monad f. This proposition is to add following default instances[1]: default fmap :: Applicative f => (a -> b) -> f a -> f b f `fmap` m = pure f <*> m default pure :: Monad f => a -> f a pure = return default (<*>) :: Monad f => f (a -> b) -> f a -> f b (<*>) = liftM2 ($) The proposition is intended as step towards implementing whole hierarchy of Functor f => (Pointed f =>?) => Applicative f => Monad f[2] Discussion period: 2 weeks Regards [1] It's using DefaultSuperclassInstances extentions: http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances [2] Trivial implementation is shown here: http://thread.gmane.org/gmane.comp.lang.haskell.libraries/16196 I believe that in such case the Pointed instance comes at nearly zero cost.

7 11