April 2016 - Libraries

Types for Data.Sequence pattern synonyms
by David Feuer 25 Apr '16

25 Apr '16

As discussed, I plan to add pattern synonyms Empty, :<|, and :|> to make working with sequences more convenient. The remaining question is what types they should have. From the Data.Sequence standpoint, the best thing would be to make them work *only* for Seq, so that the Seq type will be inferred from their use. However, modules using multiple sequence types might benefit from more flexibility, via ad hoc classes. This, however, requires that something else pin down the sequence type, and could cause more confusing error messages. I'm leaning toward the simple, monomorphic approach, but I figured I should ask here in case anyone disagrees strongly. {-# LANGUAGE PatternSynonyms, ScopedTypeVariables, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances, ViewPatterns #-} module Patt where import Data.Sequence as S import Prelude as P class FastFront x xs | xs -> x where fcons :: x -> xs -> xs fviewl :: xs -> ViewLS x xs class FastRear x xs | xs -> x where fsnoc :: xs -> x -> xs fviewr :: xs -> ViewRS x xs class FastEmpty x xs | xs -> x where fMkEmpty :: xs fIsEmpty :: xs -> Bool instance FastFront a (Seq a) where fcons = (<|) fviewl xs = case viewl xs of EmptyL -> EmptyLS y :< ys -> ConsLS y ys instance FastFront a [a] where fcons = (:) fviewl [] = EmptyLS fviewl (x : xs) = ConsLS x xs instance FastRear a (Seq a) where fsnoc = (|>) fviewr xs = case viewr xs of EmptyR -> EmptyRS ys :> y -> SnocRS ys y instance FastEmpty a (Seq a) where fMkEmpty = mempty fIsEmpty = S.null instance FastEmpty a [a] where fMkEmpty = [] fIsEmpty = P.null data ViewLS x xs = EmptyLS | ConsLS x xs data ViewRS x xs = EmptyRS | SnocRS xs x pattern x :<| xs <- (fviewl -> ConsLS x xs) where x :<| xs = fcons x xs pattern xs :|> x <- (fviewr -> SnocRS xs x) where xs :|> x = fsnoc xs x pattern Empty <- (fIsEmpty -> True) where Empty = fMkEmpty

4 3

prelude-compat, prelude2010
by Henning Thielemann 16 Apr '16

16 Apr '16

Here is my attempt to make packages compile with GHC-7.10 and older compilers without warnings: https://hackage.haskell.org/package/prelude-compat-0.0/candidate https://hackage.haskell.org/package/prelude2010-0.0/candidate The idea is that prelude2010:Prelude maintains the export list of haskell2010:Prelude such that you are saved both from identifier conflicts and warnings about redundant imports of Data.Foldable etc. Unfortunately, when I try to use it on GHC-7.8.4 together with base-noprelude, I am told that base-noprelude cannot be installed with Cabal-1.22. :-( However, when thinking about adapting all my packages to this work-around I'd prefer to switch to the real solution, namely split base packages that can be upgraded independently from GHC.

1 1

Re: GHC 8 and Template Haskell
by Ryan Scott 15 Apr '16

15 Apr '16

> I've done a quick grep for InstanceD over the stackage-nightly-subset of Hackage: Wouldn't we also need to check for the instanceD function from Language.Haskell.TH.Lib as well? I know several of my packages use that exclusively over the InstanceD constructor, and I imagine others do as well. Ryan S.

2 2

GHC 8 and Template Haskell
by Iavor Diatchki 15 Apr '16

15 Apr '16

Hello, Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do we have a way to generate instances with such pragmas using Template Haskell? I can't seem to find a way to do this, which is unfortunate. If I am not missing anything, would there be objections to adding it to the TH library before the next release---I would volunteer to do the change ASAP. Let me know, -Iavor

6 9

New maintainers of containers
by Milan Straka 13 Apr '16

13 Apr '16

Hi David and Edward, following the announcement and small discussion at libraries@haskell, I have added you both as maintainers of containers on github and on hackage. The idea is that David will take care of Data.Sequence, and CLC will manage the rest (at least until someone else appears, like wren). I have added only you Edward on behalf of CLC, but you can add others if you like (you should have the rights to do it). I would like to note that since containers are widely used and needed by GHC itself, I consider the CLC to have the final word if any disagreement ever arises between CLC and other container maintainers (David, wren, ...). Also please consider backward compatibility very highly. I will stop reading libraries@haskell and also containers github notifications soon, but feel free to write me an email or mention me on github (using @foxik) if you need to contact me. Cheers, Milan Straka

2 1

Proposal: Add functions to get consecutive elements to Data.List
by Johan Holmquist 13 Apr '16

13 Apr '16

I propose adding two new functions to Data.List: zipConsecutives :: [a] -> [(a,a)] zipConsecutives xs = zip xs (tail xs) zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b] zipConsecutivesWith f xs = zipWith f xs (tail xs) (with possibly more efficient implementations) The Trac feature request is at https://ghc.haskell.org/trac/ghc/ticket/11815 . Why These functions are useful when one wants to process consecutive pairs of elements in a sequence, which is not uncommon. The ticket lists some examples, reiterated here: -- diff consecutive elements: diffs = zipConsecutivesWith (flip (-)) -- determine if list is ascending (similar for descending and strict): isAscending = and . zipConsecutivesWith (<=) -- an old friend of ours: fibs = 1 : 1 : zipConsecutivesWith (+) fibs -- get the edges of a closed path defined by points (ps): edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps) Why add to Data.List (and base) The definition must either use an extra equation for the empty list case: zipConsecutives [] = [] zipConsecutives xs = zip xs (tail xs) which makes it non practical to define inline at each use site. Or one may omit the empty list equation, which is safe (thanks to laziness), but that may not be immediately obvious. (It wasn't to me anyway.) The tail function is generally considered unsafe so it is not desirable to force the user to use it. The proposed functions would offer an alternative. The Data.List module is often imported unqualified, so new identifiers may cause collissions. I do find it rather unlikely that the proposed names would cause such problems, however. Deadline for discussion: 2016-05-31.

9 16

Re: Proposal: Add functions to get consecutive elements to Data.List
by Johan Holmquist 13 Apr '16

13 Apr '16

That is certainly an improvement to using tail for this situation. The proposal still stands though for reasons of general utility. It is preferable to not having to repeat the variable name for example. 2016-04-13 8:47 GMT+02:00 David Turner <dct25-561bs(a)mythic-beasts.com>: > Hi there, > > The idiom I normally use for this is 'zip xs (drop 1 xs)'. By using 'drop > 1' instead of 'tail' it handles the empty case without partiality or > needing an extra equation. Does that work for you? > > Cheers, > > David > On 12 Apr 2016 21:55, "Johan Holmquist" <holmisen(a)gmail.com> wrote: > > I propose adding two new functions to Data.List: > > zipConsecutives :: [a] -> [(a,a)] > zipConsecutives xs = zip xs (tail xs) > > zipConsecutivesWith :: (a -> a -> b) -> [a] -> [b] > zipConsecutivesWith f xs = zipWith f xs (tail xs) > > (with possibly more efficient implementations) > > The Trac feature request is at > https://ghc.haskell.org/trac/ghc/ticket/11815. > > > Why > > These functions are useful when one wants to process consecutive pairs > of elements in a sequence, which is not uncommon. The ticket lists > some examples, reiterated here: > > -- diff consecutive elements: > diffs = zipConsecutivesWith (flip (-)) > > -- determine if list is ascending (similar for descending and strict): > isAscending = and . zipConsecutivesWith (<=) > > -- an old friend of ours: > fibs = 1 : 1 : zipConsecutivesWith (+) fibs > > -- get the edges of a closed path defined by points (ps): > edges ps = zipConsecutivesWith makeEdge (ps ++ take 1 ps) > > > Why add to Data.List (and base) > > The definition must either use an extra equation for the empty list case: > > zipConsecutives [] = [] > zipConsecutives xs = zip xs (tail xs) > > which makes it non practical to define inline at each use site. Or one > may omit the empty list equation, which is safe (thanks to laziness), > but that may not be immediately obvious. (It wasn't to me anyway.) The > tail function is generally considered unsafe so it is not desirable to > force the user to use it. The proposed functions would offer an > alternative. > > > The Data.List module is often imported unqualified, so new identifiers > may cause collissions. I do find it rather unlikely that the proposed > names would cause such problems, however. > > > Deadline for discussion: 2016-05-31. > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > >

1 0

Proposal: Make Semigroup as a superclass of Monoid
by Jeremy 11 Apr '16

11 Apr '16

The proposal to make Semigroup a superclass of Monoid was discussed a while ago [1], and the conclusion was to "put this off until the dust has settled from the AMP and FT changes". Now that 7.10 is out, I would like to re-propose. The proposed plan is similar to AMP, but less invasive, as (in my subjective experience) user-defined Monoids are much less common than user-defined Monads. 1. GHC 7.12 will include Semigroup and NonEmpty in base. All Monoid instances, and anything else which forms a Semigroup, will have a Semigroup instance. GHC will issue a warning when it encounters an instance of Monoid which is not an instance of Semigroup. 2. GHC >7.12 will define Monoid as a subclass of Semigroup. Stage 2 could be delayed - or in the extreme case, cancelled - if the warnings following stage 1 indicate that the proposal would cause significant breakage of existing code, although this is not anticipated. The rationale for this change is: 1. Semigroup is a popular package (this is relevant in combination with the following point). 2. Using an existing Monoid as a Semigroup requires redefining it (or WrappedMonoid), leading to much boilerplate and duplication. 3. NonEmpty is often redefined by beginners (or those who don't think it's worth having an extra dependency for). [1] https://mail.haskell.org/pipermail/libraries/2013-June/020188.html -- View this message in context: http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a-superclas… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

28 61

I can no longer maintain containers
by Milan Straka 08 Apr '16

08 Apr '16

Hi all, I am writing to let you know that I am no longer able to maintain the containers package. I have enjoyed working on containers for several years, but I can no longer find the time needed for the job (with two little kids and building a house). I am not sure what is the best future of the containers package -- it could go to CLC, or it could get a new maintainer. If you look at the commit logs and on the github issues/requests, you will find out that David Feuer has a thorough understanding of the package (notably Data.Sequence) and has been competently moderating the issues/requests for some time now, so he would be the first choice. (I did not contact him sooner, so it is surprise for him as well -- sorry, David :-) Could I humbly ask David/CLC members/anyone for comments? Cheers, Milan Straka

12 20

Names for Data.Sequence pattern synonyms
by David Feuer 06 Apr '16

06 Apr '16

Milan Straka and I agree that we want Data.Sequence to offer pattern synonyms to make it more convenient to work with the ends of sequences. I wanted to check with everyone here what names to use. Relevant names already exposed: 1. <|, |>, and empty for cons, snoc, and empty 2. data ViewL a = EmptyL | a :< Seq a, and the equivalent on the right. I suggested Empty, :<<, and :>> as the pattern synonyms, the latter chosen for the relative convenience of the double tap. Milan suggested (correctly, I suspect) that the greater clarity of Empty, :<|, and :|> is worth the price in typing.

3 2