March 2016 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Proposal: add liftA4 and liftA5 to match liftM4 and liftM5
by David Feuer 14 Jul '16

14 Jul '16

Since Applicative is supposed to be important now, I figure we should get these in.

12 33

Proposal: add chunksOf to Data.Sequence
by David Feuer 06 May '16

06 May '16

Data.List.Split.chunksOf n xs breaks up a list xs into chunks of n elements each. The internal "splitMap" function Data.Sequence uses to implement zipWith supports a simple and efficient implementation of chunksOf. All in favor, say "aye". Also, I'm still waiting for a response (any response) to my "cycleN" proposal. David

5 6

Proposal: Export cycleN from Data.Sequence
by David Feuer 26 Apr '16

26 Apr '16

Yesterday I rewrote `*>` for Data.Sequence (again), using an internal function cycleN :: Int -> Seq a -> Seq a The name of the function is based on that of Data.Sequence.iterateN. cycleN takes a sequence and cycles it as many times as requested: cycleN 0 $ fromList [1,2] = [] cycleN 5 $ fromList [1,2] = [1,2,1,2,1,2,1,2,1,2] The function is written to maximize sharing in the result sequence and to minimize construction time. Specifically, cycleN n xs should take something like O(|xs| + log n) space (of which all but O(log |xs| + log n) is shared with the structure of xs) and O(log |xs| + log n) time. With current (on GitHub) Data.Sequence exports, the only way to get this functionality with these time and space bounds is to combine replicate with *> : cycleN n xs = replicate n () *> xs This strikes me as a bit unpleasant. David

3 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

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

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