- Libraries - Haskell.org

Proposal: Add Peano numbers to base
by M Farkas-Dyck 14 Jan '16

14 Jan '16

I have seen these redefined many times now. Examples: https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano… https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano… https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.… https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.h… https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano I often see them used as DataKinds. Too, operations on them can be lazy, which is sometimes useful. I filed a ticket: https://ghc.haskell.org/trac/ghc/ticket/11402 Discussion period: 2 weeks

7 7

Proposal: Add Semigroup and Monoid instances for (:~:)
by David Feuer 14 Jan '16

14 Jan '16

These are not likely to be *useful*, but they fall easily into the general bucket of "exactly one sensible instance exists". instance Semigroup (a :~: b) where r <> _ = r instance a ~ b => Monoid (a :~: b) where mempty = Refl mappend r _ = r

3 3

GHC.Generics and instances of Functor, Applicative, etc?
by Conal Elliott 12 Jan '16

12 Jan '16

I'm using GHC.Generics and have noticed that the data types defined there don't have instances of the standard classes (at least not defined in that module), such as Functor, Applicative, Foldable and Traversable. It'd be very useful to be able to rely on such instances, so that one can define instances of custom types via instances of the generic types. (Hopefully, the compiler can remove most or all conversion overhead) Is there any reason not to add these generic instances? -- Conal

2 2

Re: Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec
by Ryan Scott 11 Jan '16

11 Jan '16

> In transformers-0.5 it seems that I have to implement Eq1, Ord1, Show1 instances manually. For better or worse, that is indeed the case. Before, Eq1/Ord1/Read1/Show1 relied on the type argument having an implicit dictionary to use, which is why you could get away with piggybacking off of your existing Eq/Ord/Read/Show instances. Now, Eq1, Eq2, and friends rely on explicit dictionary passing, so they're strictly more powerful than Eq et al. > Is there some assistance to define eq1 and compare1 for an ADT? At the moment, no. Sometime in the future, I want to do two things which should make the situation a little better: 1. Write a language extension to derive Eq1/Eq2/etc. It definitely won't be making it into GHC 8.0 due to time constraints, plus I need to propose a design. And... 2. ...I should write a Template Haskell shim which implements the proposed design. I already have a package called deriving-compat [1] which has done this (but only for recent changes to -XDeriveFoldable), so that would probably be a logical place to put it. Until then, if you need to hand-roll Eq1/Eq2/etc. instances that align with your Eq instances, I'd recommend copying the output of ghc -ddump-deriv, copying the generated instances, and replacing the necessary calls with dictionary arguments. For example, given this instance: data Example a = Example Int a deriving Eq Compiling with ghc -ddump-deriv gives you this (after some code cleanup): instance Eq a => Eq (Example a) where Example i1 a1 == Example i2 a2 = i1 == i2 && a1 == a2 e1 /= e2 = not (e1 == e2) Then, you can create an Eq1 instance with some minor adjustments: instance Eq1 Example where liftEq eq (Example i1 a1) (Example i2 a2) = i1 == i2 && eq a1 a2 > What are the use cases where eq1 was not powerful enough and liftEq is needed? The previous type signature of Data.Functor.Classes in transformers-0.4 resulted in some awkward instances, a prime example being found in Data.Functor.Compose: import Data.Functor.Classes(Eq1(..)) newtype Compose f g a = Compose (f (g a)) instance (Functor f, Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a) where Compose x == Compose y = eq1 (fmap Apply x) (fmap Apply y) instance (Functor f, Eq1 f, Eq1 g) => Eq1 (Compose f g) where eq1 = (==) newtype Apply g a = Apply (g a) instance (Eq1 g, Eq a) => Eq (Apply g a) where Apply x == Apply y = eq1 x y This is a super-kludgey instance because it requires f to be a Functor instance. In general, having these Functor constraints pop up everywhere results in less efficient instances, and it won't work at all for many GADT-like constructions that can't have legal Functor instances. With the new API, there is no need for these Functor constraints: import Data.Functor.Classes(Eq1(..)) newtype Compose f g a = Compose (f (g a)) instance (Eq1 f, Eq1 g) => Eq1 (Compose f g) where liftEq eq (Compose x) (Compose y) = liftEq (liftEq eq) x y Ryan S. ----- [1] http://hackage.haskell.org/package/deriving-compat

2 4

Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec
by Henning Thielemann 10 Jan '16

10 Jan '16

In transformers-0.5:Data.Functor.Classes class methods like eq1 are replaced by liftEq. With transformers-0.4 I could define: data T a = complicated definition ... deriving (Eq, Ord, Show) instance Eq1 T where eq1 = (==) instance Ord1 T where compare1 = compare instance Show1 T where showsPrec1 = showsPrec In transformers-0.5 it seems that I have to implement Eq1, Ord1, Show1 instances manually. Is there some assistance to define eq1 and compare1 for an ADT? What are the use cases where eq1 was not powerful enough and liftEq is needed?

1 0

Foldable.Mapped
by Henning Thielemann 04 Jan '16

04 Jan '16

I found the following data type useful when working with the Foldable class: {- | It holds: > foldMap f . Mapped g = foldMap f . fmap g but use of 'Mapped' avoids 'Functor' constraint. -} data Mapped f a b = Mapped (a -> b) (f a) instance (Foldable f) => Foldable (Mapped f a) where foldMap g (Mapped f xs) = Fold.foldMap (g . f) xs foldr g x (Mapped f xs) = Fold.foldr (g . f) x xs foldl g x (Mapped f xs) = Fold.foldl (\acc -> g acc . f) x xs Should it be added to Data.Foldable?

4 4

Haddock with GHC 8
by Dominic Steinitz 14 Dec '15

14 Dec '15

Hello All, I submitted a PR for Haddock to support mathjax on 16 May. As I understand it, the maintainer of Haddock did not wish to apply it immediately as it would change interface files (although I have to admit I don’t know what this entails). Are there any plans to release a new version of Haddock along with GHC 8? Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

3 4

cabal-install 1.24
by Jeremy 10 Dec '15

10 Dec '15

What's the status of cabal-install 1.24? https://github.com/haskell/cabal/milestones shows it as 3 months overdue and 12% complete. My concern is over https://github.com/haskell/cabal/pull/2826, which is a show-stopper for some of my work, but doesn't seem to be in any released branch. -- View this message in context: http://haskell.1045720.n5.nabble.com/cabal-install-1-24-tp5824017.html Sent from the Haskell - Libraries mailing list archive at Nabble.com.

2 1

3 release policy and -Wno-compat
by Jeremy 30 Nov '15

30 Nov '15

The draft of the 3 release policy has a very strict requirement for warnings, "without causing warnings even when compiled with -Wall". This causes breaking changes to be spread out over a number of years because of deprecation warnings. I propose that "-Wall" in this sentence be replaced with "-Wall -Wno-compat". As we are addressing an audience who wish to suppress a specific category of warnings, it seems reasonable to ask that they make this explicit. (I would also prefer for -Wcompat to be on by default, but that would be another discussion, if and only if this proposal is accepted.) -- View this message in context: http://haskell.1045720.n5.nabble.com/3-release-policy-and-Wno-compat-tp5823… Sent from the Haskell - Libraries mailing list archive at Nabble.com.

3 9

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