- Libraries - Haskell.org

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

A better type signature for `forM_`
by Erik de Castro Lopo 01 Apr '16

01 Apr '16

Hi all, I was recently faced with some unexpected behaviour from a piece of code that type checks and has zero warnings (even with -Wall). The code is below (and depends on the hashtables package). The error was using the <$> operator instead of the =<< operator. Using the former, it just builds up a list of IO actions that never get run. As pointed out to me on IRC (thanks pjdeport), chaning the type signature of `forM_` to forM_' :: (Monad m, Foldable t) => t a -> (a -> m ()) -> m () would have resulted in an error. Yes, this change would break existing code (breaking code would require an explicit `void $` inside the `forM_`) but does anyone else think this is a good idea? Erik import Control.Monad import qualified Data.HashTable.IO as HT type EvenCache = HT.BasicHashTable Int Bool main :: IO () main = do ht <- buildTable xs <- HT.toList ht putStrLn $ "cache: length " ++ show (length xs) buildTable :: IO EvenCache buildTable = do ht <- HT.new forM_ pairs $ \ (k,v) -> maybe (HT.insert ht k v) (const $ abort k) <$> HT.lookup ht k return ht where xs = [1 .. 10] :: [Int] pairs = map (\ i -> (i, even i)) xs abort k = error $ "cache: duplicate key " ++ show k ++ "." -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

9 12

Warn about unwanted instances in a modular way
by Henning Thielemann 23 Mar '16

23 Mar '16

I like to propose the following way to warn about instances that are unwanted by some programmers. First step is to mark the instances at their definition site like so: {-# WARN_INSTANCE tuple #-} instance Foldable ((,) a) where ... {-# WARN_INSTANCE tuple #-} instance Functor ((,) a) where ... {-# WARN_INSTANCE tuple #-} instance Foldable ((,,) a b) where ... {-# WARN_INSTANCE tuple #-} instance Functor ((,,) a b) where ... This way, all the above instances are collected in an instance group labelled 'tuple'. At the use sites we introduce a GHC warning option like -fwarn-instance=tuple. This warns about any place where any of the 'tuple' instances is used. We can either place GHC-Options: -fwarn-instance=tuple in a Cabal package description in order to issue warnings in a whole package or we can put {-# OPTIONS_GHC -fwarn-instance=tuple #-} at the top of a module in order to enable the warning per module. Another candidate for an instance group might be 'numeric' for numeric instances of functions and tuples in the NumInstances package. What does it mean to use an instance? I would say, if omitting an instance X Y would lead to a "missing instance" type error at place Z in a module, then instance X Y is used at place Z. There might be an even more restrictive option like: -fforbid-instance=tuple This would not only warn about an instance usage, but it would cause a type error. Essentially it should treat all 'tuple' instances as if they were not defined. (Other instances might depend on 'tuple' instances and if the 'tuple' instances weren't there the compiler would not even reach the current module. I do not know, whether this case needs special treatment. We might require that any instance depending on 'tuple' must be added to the 'tuple' group as well or it might be added automatically.) The advantage of a type error is that we see all problems from 'tuple' instances also in the presence of other type errors. Warnings would only show up after a module is otherwise type correct. This solution requires cooperation of the instance implementor. Would that work in practice? Otherwise we must think about ways to declare instance groups independently from the instance declaration and we get the problem of bringing the instance group names into the scope of the importing module. A separate discussion must be held on whether -fwarn-instance=tuple should be part of -Wall. I think that people should be warned about 'tuple' instances early because they won't expect that there is a trap when using 'length' and 'maximum' and so on. One might also think about generalizations, e.g. whether {-# WARN_INSTANCE tuple, functor #-} should be allowed in order to put an instance in several groups or whether there should be a way to compose a group from subgroups. Another topic would be a form of instance group disambiguation. Instance groups might be qualified with module or package names. I think package names are more appropriate, like so: -fwarn-instance=base:tuple

1 0