February 2016 - Libraries

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

Proposal: Add conspicuously missing Functor instances for tuples
by David Feuer 23 Feb '16

23 Feb '16

For some reason I really can't imagine, it seems the only tuple type with a Functor instance is (,) a. I was astonished to find that fmap (+1) (1,2,3) doesn't work. Since this is *useful*, and there is *only one way to do it*, I propose we add the following: instance Functor ((,,) a b) where fmap f (a,b,c) = (a,b,f c) instance Functor ((,,,) a b c) where fmap f (a,b,c,d) = (a,b,c,f d) etc. I would really love to see these make 8.0.0, but if that's impossible then so be it.

18 29

"Excuse me, I think this i my stop..." - Resigning from the Platform
by Mark Lentczner 22 Feb '16

22 Feb '16

I think this is the right time for me to exit: The truth is, I still can't bring myself to use a version of Haskell post the Foldable-Traversable-aPocalypse, let alone some future Haskell after the changes now in the works. My personal machines are all still 7.8. My personal projects are all pre-FTP. The Haskell I love to code in, the Haskell I'm passionate about, the Haskell I've advocated for real world use, and the Haskell I like to teach, is 7.8, pre-FTP. It's not that I'm dead set against change and evolution in a language, or even breaking changes. But FTP and beyond are changes that have lost the balance that Haskell had between abstraction and clarity, between elaborate and practical engineering. I don't see any restraint going forward, so I'm getting off the train. This puts me in an odd position with respect to Haskell Platform: I find myself building the Platform for a version of Haskell that I don't use. This isn't healthy for either the Platform or me. Hence, I'm resigning as release manager. I am sad because I believed that Haskell's path to much wider adoption was within reach. Now, especially with the ramping up of the Haskell Prime committee, which seems preordained to codify FTP and beyond into standard, we are approaching our Algol 68 moment: Building a major language revision with less opportunity than it's predecessor. I'll still see you 'round at meet-ups and conferences. I'll just be coding with an older accent. - Mark "mzero" Lentczner

5 6

Re: Discussion: GHC.Generics vs. transformers Sum/Product
by Ryan Scott 20 Feb '16

20 Feb '16

Indeed, I've been meaning to fix Trac #9043 [1] for a while. Its progress had been blocked by a separate issue [2] that will be fixed in 8.0. Now there's nothing blocking it, and I have a GHC fork [3] that finishes Oliver Charles' work on adding more instances to GHC.Generics datatypes. I'll probably submit it once 8.0 is released (since the window for new additions for 8.0 has already passed). In the meantime, if there's an instance you want to see added, file an issue on https://github.com/RyanGlScott/ghc! Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/9043 [2] https://ghc.haskell.org/trac/ghc/ticket/9766 [3] https://github.com/RyanGlScott/ghc/tree/ghc-generics-instances

2 1

Discussion: GHC.Generics vs. transformers Sum/Product
by David Feuer 18 Feb '16

18 Feb '16

GHC.Generics defines the following pleasantly-named types data (f :+: g) a = L1 (f a) | R1 (g a) and data (f :*: g) a = f a :*: g a represent lifted sums and products (analogous to Either and (,), respectively). These types, however, are given very few instances. Most notably, they lack even Functor instances! Entirely equivalent types, with less pleasant names, appear in transformers Data.Functor.Sum and Data.Functor.Product, where they are given plenty of instances. Is there some way to bring these things together, preferably with the names from GHC.Generics and the instances from Data.Functor.Sum and Data.Functor.Product?

3 3

Bifunctor instance for (,) is not strictly law-abiding
by David Feuer 17 Feb '16

17 Feb '16

I don't think we should fix this, because it would break code, but I do think we should document it. Bifunctor law: bimap id id = id But actually, bimap id id _|_ = (_|_, _|_)

2 3

Process proposal: Require explicit user-oriented timelines in library proposals
by Ben Gamari 14 Feb '16

14 Feb '16

tl;dr. I think proposals should include a user-oriented timeline, e.g. [2] Hello everyone, Recently I've been doing some thinking about library change roadmap and in particular our process for considering changes. While this process has without question improved remarkably in the last few years, I think there is still some room for improvement in communicating future plans, in particular to users. From the user's perspective there are three important points in time (let's call them milestones) associated with a library proposal (using MonadFail as an example), A. When can I start asking for warnings? This is the time when we add warnings notifying users of the coming change to -Wcompat (e.g. this is 8.0 in the case of MonadFail) B. When can I start conveniently acting upon these warnings? This is the point where enough time has passed that the user can take action on the warning in a manner consistent with the three-release policy (e.g. 8.4 in the case of MonadFail?) Ideally proposals would also include concrete examples of the sort of refactoring that would typically be necessary. C. For how long can I procrastinate? This is the point where the user's code will break if they have not taken action (e.g. 8.6 in the case of MonadFail?) In the case of the proposals currently on the roadmap [1] it can sometimes be rather tricky to determine exactly where each of these points fall as the proposals tend to discuss implementation and leave the implications on the user implicit. I propose that we require that formal proposals lay out a user-oriented timeline explicitly. I have adapted the Semigroup-Monoid proposal [2] to demonstrate what this might look like. Of course, the timeline is a simplification of reality: In some cases, there may be multiple times associated with each milestone. For instance, in the case of the Semigroup-Monoid proposal it would seem that there are two point Cs, * Things break once in Phase 2b since the user must provide Semigroup instances to go along with their Monoid instances * Things break again in Phase 4 since the user must remove mappend definitions from the Monoid instances This should be made explicit in the timeline [3]. How does this sound? Cheers, - Ben [1] https://prime.haskell.org/wiki/Libraries/Proposals [2] https://ghc.haskell.org/trac/ghc/wiki/BenGamari/ProposalMilestoneExample#Mi… [3] Although arguably this proposal should be two distinct pieces: * Add Semigroup as a superclass of Monoid * Remove mappend from Monoid If the Semigroup-Monoid proposal were so divided it would break down quite cleanly on the timeline proposed above.

3 5

Proposal: make minimumBy/maximumBy go through foldl', not foldr1
by Roman Cheplyaka 11 Feb '16

11 Feb '16

I just realized (thanks to this reddit thread[1]) that minimumBy is now implemented through foldr1. Previously (before FTP), minimumBy from Data.List used foldl1, while minimumBy from Data.Foldable used foldr1. I think that the way these were merged was a mistake. Let's admit that the absolute majority of use cases for minimumBy are numbers, for which the comparison functions are strict in both arguments. Even for something like Bool, where comparison could potentially be in one of the arguments, the standard compare method is derived and is strict. Now, for Foldable, there isn't necesarily a connection between the direction and the way fold is performed. For example, for Data.Map.Map both folds are tail-recursive. Yet foldr is non-tail-recursive at least for: - good old lists - anything that uses the same convention for foldl/foldr as lists - anything that defines its foldable instance through conversion to lists - anything that uses the default implementation of foldr/foldr1 I also put a simple microbenchmark[2] to show the difference in performance; on it, the proposed implementation is more than 20x faster than the current one. [1]: https://www.reddit.com/r/haskell/comments/3qpefo/a_very_unfortunate_error_m… [2]: http://lpaste.net/714261956202070016

8 12

Bug tracker for cpphs
by Andrés Sicard-Ramírez 01 Feb '16

01 Feb '16

Hi Malcolm, (I'm resending my old question to the libraries mailing list) Is there a bug tracker for cpphs? Best, -- Andrés

4 6