- Libraries - Haskell.org

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

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