- Libraries - Haskell.org

Re: Proposal: Add conspicuously missing Functor instances for tuples
by Ryan Scott 22 Mar '16

22 Mar '16

Strong +1 from me. We derive Eq/Ord/Read/Show/etc. for all tuple types of size up to 15 as it is, we might as well do the same for Functor. (Personally, I'd even argue for adding Foldable and Traversable instances as well, but the Foldable instance for pairs has proven to be pretty controversial...) Ryan S.

39 143

Cabal on Mac OSX EL Capitan - forwarding DYLD_LIBRARY_PATH
by tamarind code 21 Mar '16

21 Mar '16

Hi, There was a discussion in github about stack (see link below) where the conclusion seems to be pointing towards a bug in Cabal on Mac OSX EL Capitan related to forwarding DYLD_LIBRARY_PATH https://github.com/commercialhaskell/stack/issues/1161#issuecomment-1584739… At the moment the suggested workaround is to disable System Integrity Protection which sounds a bit scary to me. So I thought this might be a good idea to reported to someone in a Cabal team. At the moment I am using an Ubuntu Virtual Machine to avoid having to mess with SIP on my mac. Hope some clever/kind person from the Haskell community would be able to fix this soon. Thanks Sam

4 5

Implement traverseMaybe in Data.Map, Data.IntMap, etc
by Fumiaki Kinoshita 10 Mar '16

10 Mar '16

As far as I know, the most general form of a function that allows traversing and filtering is: type Filter s t a b = foall f. Applicative f => (a -> f (Maybe b)) -> s -> f t In my witherable[0] package, I defined `Witherable` as a subclass of `Traversable` to provide such operation for various containers. class T.Traversable t => Witherable t where wither :: Applicative f => (a -> f (Maybe b)) -> t a -> f (t b) ... However, the `wither` for `Map` is currently inefficient because it is defined in terms of `traverse` and `mapMaybe`, so it traverses the container twice. Efficient implementation.would have to use the hidden constructors. I would like to propose adding `traverseMaybe` and `traverseMaybeWithKey` for `Data.Map`, `Data.IntMap`, and their strict variants (I'm suggesting more conservative name because wither might sound too unusual or poetic for a standard library. I like 'wither' though). A possible implementation would be like this: traverseMaybeWithKey :: Applicative f => (k -> a -> f (Maybe b)) -> Map k a -> f (Map k b) traverseMaybeWithKey _ Tip = pure Tip traverseMaybeWithKey f (Bin _ kx x l r) = maybe merge (link kx) <$> f kx x <*> traverseMaybeWithKey f l <*> traverseMaybeWithKey f r I think there is potential demand for this function as well as mapMaybe. [0] http://hackage.haskell.org/package/witherable

2 1

Alternative Proxy
by Fumiaki Kinoshita 09 Mar '16

09 Mar '16

This is the only possible definition...so it should exist instance Alternative Proxy where empty = Proxy _ <|> _ Proxy

4 6

Add `take`/`drop`/`splitAt` to `Data.Map`/`Data.Set`
by Gabriel Gonzalez 08 Mar '16

08 Mar '16

I would like to propose adding `take`/`drop`/`splitAt` to both `Data.Map` and `Data.Set` as originally requested in: https://github.com/haskell/containers/issues/135 <https://github.com/haskell/containers/issues/135> The motivation behind this proposal is three-fold: * for convenience - these functions are commonly used to implement pagination or previews of maps/sets * for type accuracy - the public API impose an unnecessary `Ord` constraint * for efficiency - these can be implemented more efficiently using the internal API Currently the only way you can implement this functionality via the public API is to use `lookupIndex`/`elemAt` + `split`. For example, one way to implement `Data.Set.take` is: take :: Ord a => Int -> Set a -> Set a take n m | n < 0 = empty | size m <= n = m | otherwise = lt where (lt, _) = split k m k = elemAt n m {-# INLINE take #-} This implementation incurs an unnecessary `Ord` constraint due to a roundabout way of computing `take`: this extracts the element at the given index and then works backwards from the element’s value to partition the set using O(log N) comparisons. We could eliminate all of the comparisons by using the internal API. Intuitively, we expect that the performance of `Data.Set.take` would benefit from avoiding those unnecessary comparisons and also avoiding traversing the `Set`’s spine twice. So I tested that hypothesis by implementing `take` via the internal API like this: take :: Int -> Set a -> Set a take n0 s0 = go s0 n0 where go s@(Bin sz x l r) n = if sz <= n then s else let sl = size l in if n <= sl then go l n else link x l (go r $! n - sl) go Tip _ = Tip {-# INLINE take #-} I then added the following benchmark to `benchmarks/Set.hs`: diff --git a/benchmarks/Set.hs b/benchmarks/Set.hs index 3a6e8aa..03c99fb 100644 --- a/benchmarks/Set.hs +++ b/benchmarks/Set.hs @@ -31,6 +31,7 @@ main = do , bench "union" $ whnf (S.union s_even) s_odd , bench "difference" $ whnf (S.difference s) s_even , bench "intersection" $ whnf (S.intersection s) s_even + , bench "take" $ whnf (S.take (2^11)) s , bench "fromList" $ whnf S.fromList elems , bench "fromList-desc" $ whnf S.fromList (reverse elems) , bench "fromAscList" $ whnf S.fromAscList elems Here is the performance on my machine when implementing `take` via the public API: benchmarking take time 272.8 ns (266.7 ns .. 278.1 ns) 0.997 R² (0.996 R² .. 0.998 R²) mean 266.3 ns (261.8 ns .. 270.8 ns) std dev 15.44 ns (13.26 ns .. 18.95 ns) variance introduced by outliers: 75% (severely inflated) … and the performance improved by 61% from using the internal API: benchmarking take time 169.2 ns (166.1 ns .. 172.6 ns) 0.997 R² (0.996 R² .. 0.998 R²) mean 172.1 ns (169.4 ns .. 175.4 ns) std dev 10.68 ns (8.420 ns .. 15.34 ns) variance introduced by outliers: 78% (severely inflated) … and I’m guessing (but haven’t tested) that the performance gap would only increase the more expensive the comparison function gets. I haven’t performed comparative performance testing for `drop`/`splitAt` nor have I tested `Map` (because the benchmarks take a while for me to build and run) but I can perform those additional comparisons upon requests if people feel they are necessary. I haven’t yet written up a full patch since the maintainer asked me to first run this proposal by the libraries mailing list to assess whether it would be wise to expand the `containers` API to include these utilities. The deadline for discussion is two weeks.

8 12

Test email
by Gershom B 03 Mar '16

03 Mar '16

Please disregard -- sorry for the noise. Gershom

1 0

Re: Libraries Digest, Vol 150, Issue 32
by Michał J Gajda 27 Feb '16

27 Feb '16

-1(*inf) Downsides: 1. New way to make a Haskell expression that makes no semantic sense `length (1, 2)`, and it still evaluates. 2. New trick interview question that makes interviewers hated for being impractical. (Just like `join (*)`.) 3. Confuse hell out of beginners and practitioners alike. Upside: 1. One Canonical(tm) Functor instance for tuple, and pope's own claim that the other instance does not fit in our library. 2. More standard types that are Functor instances. 3. Easier to demonstrate that one can DO EVIL in Haskell too. -- Cheers Michal

1 0

GHC documentation of modules exposed by the base package
by Andrés Sicard-Ramírez 26 Feb '16

26 Feb '16

Dear all, By running in GHC 7.10.3 $ ghc-pkg field base-4.8.2.0 exposed-modules I can see various modules exposed by base-4.8.2.0 which are not documented (e.g. GHC.NUm) in http://downloads.haskell.org/~ghc/7.10.3/docs/html/libraries/index.html Which is the criterion for adding GHC documentation to the modules exposed by base? All the best, -- Andrés

2 1

SAFE: a Foldable proposal
by Thomas Tuegel 26 Feb '16

26 Feb '16

Friends, I address you this evening in the desperate hope that, though we have become divided by harsh words, we may come together again as one family in Haskell. Before, we saw as through a glass, darkly. To drive back the night, we stoked the fires of our passion. Now the heat burns us! The smoke stings our eyes! I intend to magnify what was hidden so we may see clearly by only a small flame. We came to Haskell along many paths, but the same values drew us all. One of the values dearest to us is the ability to reason statically about our programs. To enhance this ability which Haskell naturally affords us, we have devised laws to govern our type classes. Type class laws are rightly judged by their strength: the ways in which they constrain the instances we may write. When these laws bind us most tightly, we may reason most freely. With this in mind, let us turn to the Foldable class. Foldable has several laws, but I will focus on two. First, for foldr and foldMap, > foldr f z t = appEndo (foldMap (Endo . f) t) z Second, optionally, for Functors, > foldMap f = fold . fmap f There are other laws, but for my purposes, they essentially follow from the above. It is generally acknowledged that these laws are relatively weak: it is difficult to conceive an instance which violates them that is not an egregious violation. With that, I offer the following simple proposal. I doubt it will achieve consensus, but I believe it will illuminate our positions more clearly. I hope it allows us to see each other with more empathy. SAFE - Stronger Alternative Foldable Enhancement / Elucidation Foldable will gain a superclass, Alternative: > class Alternative t => Foldable t where { ... } The members of the class will not change. The class will gain the following laws to supercede the existing laws: > foldMap f empty = mempty > foldMap f (xs <|> ys) = foldMap f xs <> foldMap f ys > foldr f z empty = z > foldr f z (xs <|> ys) = foldr f (foldr f z ys) xs The laws for the other members follow in the obvious way. Some instances from base are ruled out: Identity, Either a, (,) a, Proxy, and Const m. Implementing this change would necessitate attaching warnings to those instances for the customary length of time. It is my understanding that GHC is not currently able to attach warnings to instances, but I think that would be a useful feature to add, even absent the current proposal. I think this Foldable class is better than the one we have now. These constraints are stronger because they show the connection between Alternative and Monoid. I will pause here a moment because I think this is crucial to the contention between us. Foldable could be a bridge between Alternative and Monoid. We do not agree about how much may be expected of the Foldable class. I think this is what we should expect. I think this guarantee, that there is a monoidal or Alternative structure underlying Foldable, was always the unarticulated vision behind the objections to these contentious instances. I hope that the utility and elegance of my proposal will convince you, but failing that I hope it illuminates what should be our topic of discussion: not "What is to be done about Foldable?" but rather, "What is to be expected of Foldable?" Sincerely, Thomas

5 8

Re: Haskell Foldable Wats
by Kris Nuttycombe 24 Feb '16

24 Feb '16

Oops, yes, "can't" is what I meant to type there. On Wed, Feb 24, 2016 at 2:54 PM, Manuel Gómez <targen(a)gmail.com> wrote: > On Wed, Feb 24, 2016 at 5:12 PM, Kris Nuttycombe > <kris.nuttycombe(a)gmail.com> wrote: > > make Haskell *less* internally > > consistent, just so that they can call `length (foo, bar)`. > > Can or can’t? >

1 0