- Libraries - Haskell.org

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

Fwd: Bug tracker for cpphs
by Theodore Lief Gannon 30 Jan '16

30 Jan '16

Chiming in to agree: don't be afraid of Github, it's very ergonomic. In particular, it's safe to only look at the bits relevant to your immediate needs; you don't have to know the whole system before doing anything. On Sat, Jan 30, 2016 at 12:17 PM, Andrés Sicard-Ramírez <asr(a)eafit.edu.co> wrote: > Hi Malcolm, > > On 30 January 2016 at 06:49, Malcolm Wallace <malcolm.wallace(a)me.com> > wrote: > > If someone with more experience of setting up trackers were to do the > work of creating one for cpphs (maybe on github? is that where everyone > hangs out these days?), I might be persuaded to use it. :-) > > To you set up a bug tracker in GitHub for cpphs requires only two steps: > > 1. Create a GitHub account (you already have one) > 2. Create the cpphs repository with the issues enabled. > > Best, > > -- > Andrés > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

2 1

Proposal: Data.Bool.implies
by Niklas Hambüchen 26 Jan '16

26 Jan '16

I propose to add to Data.Bool: -- | Boolean implication. implies :: Bool -> Bool -> Bool implies True x = x implies False _ = True infix 4 `implies` -- same as (==) The request for this is quite old (see e.g. http://neilmitchell.blogspot.de/2007/02/logical-implication-in-haskell.html) I believe that by not trying to use an operator for it, and keeping it in Data.Bool, we can avoid doing anything wrong. A quick superficial search on Stackage Hoogle suggests that adding this function should create no breakage (4 packages define their own function called `implies`, none of them import Data.Bool). `infix` instead of `infixl` or `infixr` to force you to bracket it; for the same reason it has the same precedence as `==`.

17 29