September 2015 - 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

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

Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Herbert Valerio Riedel 27 Nov '15

27 Nov '15

Hello *, Concluding AMP and MFP, We (David and I) proudly present you the final installment of the Monad trilogy: Monad of no `return` Proposal ============================= TLDR: To complete the AMP, turn `Monad(return)` method into a top-level binding aliasing `Applicative(pure)`. Current Situation ----------------- With the implementation of Functor-Applicative-Monad Proposal (AMP)[1] and (at some point) the MonadFail proposal (MFP)[2] the AMP class hierarchy becomes class Functor f where fmap :: (a -> b) -> f a -> f b class Functor f => Applicative f where pure :: a -> f a (<*>) :: f (a -> b) -> f a -> f b (*>) :: f a -> f b -> f b u *> v = … (<*) :: f a -> f b -> f a u <* v = … class Applicative m => Monad m where (>>=) :: m a -> (a -> m b) -> m b return :: a -> m a return = pure (>>) :: m a -> m b -> m b m >> k = … class Monad m => MonadFail m where fail :: String -> m a Consequently, the `Monad` class is left with a now redundant `return` method as a historic artifact, as there's no compelling reason to have `pure` and `return` implemented differently. Traditionally, `return` is often used where `pure` would suffice today, forcing a `Monad` constraint even if a weaker `Applicative` would have sufficed. As a result, language extensions like `ApplicativeDo`[3] have to rewrite `return` to weaken its `Monad m =>` constraint to `Applicative m =>` in order to benefit existing code at the cost of introducing magic behavior at the type level. Finally, this redundancy becomes even more significant when viewed in light of the renewed Haskell standardisation process[7]: The next Haskell Report will almost certainly incorporate the AMP (and MFP) changes, and there's no justification for the Report to retain `return` as a method of `Monad`. A good reason would have been to retain backward compatibility with Haskell 2010. However, as the AMP superclass hierarchy requires `Monad` instances to be accompanied by `Applicative` instances (which aren't part of Haskell 2010, c.f. [6]), backward compatibility with Haskell 2010 goes out the window when it comes to defining `Monad` instances (unless via use of `-XCPP` or similar). Consequently, meeting the high bar for a formal document such as the Haskell Report demands that `Monad` shall not carry a redundant `return` method that serves no purpose anymore. Moreover, getting `return` out of the way is desirable to facilitate standardising potential candidates such as the earlier mentioned `ApplicativeDo` in the future and avoids the technical debt incurred by keeping around this language wart. Proposed Change --------------- Remove `return` as a method from the `Monad` class and in its place define a top-level binding with the weaker `Applicative` typeclass constraint: -- | Legacy alias for 'pure' return :: Applicative f => a -> f a return = pure This allows existing code using `return` to benefit from a weaker typeclass constraint as well as cleaning the `Monad` class from a redundant method in the post-AMP world. A possible migration strategy is described further below. Compatibility Considerations ---------------------------- Generalizing the type signature of a function from a `Monad` constraint to its superclass `Applicative` doesn't cause new type-errors in existing code. However, moving a method to a top-level binding obviously breaks code that assumes `return` to be a class method. Foremost, code that defines `Monad` instances it at risk: ### Instance Definitions Code defining `return` as part of an instance definition breaks. However, we had the foresight to provide a default implementation in `base-4.8` for `return` so that the following represents a proper minimal instance definition post-AMP: instance Functor Foo where fmap g foo = … instance Applicative Foo where pure x = … a1 <*> a2 = … instance Monad Foo where m >>= f = … -- NB: No mention of `return` Consequently, it is possible to write forward-compatible instances that are valid under this proposal starting with GHC 7.10/`base-4.8`. Heuristically `grep`ing through Hackage source-code reveals a non-negligible number of packages defining `Monad` instances with explicit `return` definitions[4]. This has a comparable impact to the AMP, and similarly will require a transition scheme aided by compiler warnings. ### Module Import/Export Specifications A second source of incompatibility may be due to `import`s. Specifically module import that assert `return` to be a method of `Monad`, e.g.: import Control.Monad (Monad ((>>=), return)) or import Prelude hiding (Monad(..)) import Control.Monad (Monad(..)) as Monad f = Monad.return () The dual situation can occur when re-exporting `return` via module export specifications. However, given that `return` is exported by `Prelude` and the examples above are rather artificial, we don't expect this to be a major source of breakage in the case of `return`. In fact, a heuristic grep[5] over Hackage source-code revealed only 21 packages affected. ### Example for writing compatible code instance Functor Foo where fmap g foo = … instance Applicative Foo where pure x = … a1 <*> a2 = … instance Monad Foo where m >>= f = … #if !(MIN_VERSION_base(4,8,0)) return = pure #endif Migration Strategy ------------------ The migration strategy is straightforward: **Phase 1** *(GHC 8.0)*: Implement new warning in GHC which gets triggered when `Monad` instances explicitly override the default `return` method implementation. **Phase 2** *(GHC 8.2 or later)*: When we're confident that the majority of Hackage has reacted to the warning (with the help of Stackage actively pursuing maintainers to update their packages) we turn the `return` method into a top-level binding and remove the warning implemented in Phase 1 from GHC again. Discussion period ----------------- A discussion period of three weeks (until 2015-10-15) should be enough to allow everyone to chime in as well as leave enough time to make the required preparations for GHC 8.0 should this proposal pass as we hope. ---- [1]: https://wiki.haskell.org/Functor-Applicative-Monad_Proposal [2]: https://wiki.haskell.org/MonadFail_Proposal [3]: https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo [4]: https://gist.github.com/hvr/b0e34463d85b58f169d9 [5]: https://gist.github.com/hvr/afcd040783d980594883 [6]: https://ghc.haskell.org/trac/ghc/ticket/9590 [7]: https://mail.haskell.org/pipermail/haskell-prime/2015-September/003936.html --

41 98

[containers] Proposal: Change to the Data.Map Monoid
by Nick Partridge 10 Oct '15

10 Oct '15

Hi, Currently the Monoid instance for Data.Map is implemented using union/unions, which are left biased. On key collision, it discards values from the right hand side of `mappend` - https://github.com/ghc/packages-containers/blob/bae098fb0a3994bc2b0ec331300… If you compare this with the Monoid for Maybe, it's like we're defaulting to First as the monoid instance for maps. A more useful instance, however very much a breaking change, would be to make the instance depend on a Monoid (or better yet, a Semigroup) for the values in the map: instance Monoid v => Monoid (Map k v) where mappend = unionWith mappend This lets us build up maps with values in a useful Monoid, and mappend them with gusto. Thoughts? - Nick Partridge Discussion period: 2 weeks.

15 22

Proposal: pare down traversable
by David Feuer 07 Oct '15

07 Oct '15

Traversable currently has traverse, sequenceA, sequence, and mapM methods. sequence and mapM seem to be dinosaurs now. I'd like to suggest that sequenceA be turned into a deprecated function and mapM be moved from Control.Monad to Data.Traversable and re-exported from Control.Monad. I expect most instance declarations to survive unchanged. The only CPP pain point will be that instances that define sequenceA will have to define sequence instead.

5 7

Can we simplify Dynamic?
by David Feuer 02 Oct '15

02 Oct '15

Currently, data Dynamic = Dynamic TypeRep Obj deriving Typeable where type Obj = Any As a result, all of the operations must be implemented "by hand" using unsafeCoerce. The more obvious representation these days would seem to be data Dynamic where Dynamic :: Typeable a => a -> Dynamic Most of the operations then become trivial applications of Typeable functions. The only exceptions seem to be dynApply and dynApp. That there are exceptions strikes me as quite unfortunate. The easiest fix is inspired by the fact that Data.Dynamic uses funResultTy :: TypeRep -> TypeRep -> Maybe TypeRep from Data.Typeable to decide whether to coerce. It seems reasonable to add a more informative version, something like applyTypeable :: (Typeable f, Typeable a) => proxy f -> proxy a -> (forall b . (Typeable b, f ~ (a -> b)) => r) -> Maybe r On the other hand, it would be really cool if there were some more general way to get type-level information out of Typeable instances, pattern matching on the type constructors.

5 9

Proposal: Derive Lift for all data types in the template-haskell library
by Ryan Scott 26 Sep '15

26 Sep '15

The DeriveLift extension has landed in GHC HEAD, so now it's become apparent that the bikeshed needs a new coat of paint. The only Lift instances at the moment are base types [1], but with DeriveLift, it would be possible to implement Lift for many for data types with ease. I'll make (what I hope is) an uncontroversial first suggestion: we should derive Lift for every data type in the template-haskell library itself. These instances have proved to be useful for library authors who need to convert to and from the TH AST (th-desugar, for example, relies on this functionality via orphan instances [2]). Adding this would break some code out in the wild (the th-lift [3] and th-orphans [4] packages come to mind; there may be others), so I'll request feedback before marching forth with this proposal. Ryan S. ----- [1] http://hackage.haskell.org/package/template-haskell-2.10.0.0/docs/Language-… [2] http://hackage.haskell.org/package/th-desugar-1.5.4.1/docs/src/Language-Has… [3] http://hackage.haskell.org/package/th-lift [4] http://hackage.haskell.org/package/th-orphans

3 4