As Sean pointed out there is already a thread about this issue. I agree with Erik’s opinion, https://mail.haskell.org/pipermail/libraries/2014-December/024509.html :

I'm +1 on the obviously useful instances (Data, Functor) and wouldn’t mind the others either, since I don't see any downsides.

Simple use case for Functor is e.g. fromIntegral <$> s — Sean, is there a trac ticket for this issue? I could make a patch early next week, as this seems to be discussed previously. - Oleg

On 21 Feb 2015, at 20:21, Joachim Breitner wrote:

Hi,

Am Samstag, den 21.02.2015, 17:34 +0200 schrieb Oleg Grenrus:

...

I propose to add Functor, Applicative, Monad, Foldable, and Traversable and maybe even MonadFix instances to wrapper newtypes in the Data.Monoid module.

can you explain when these are useful?

Especially, the Monad instance might be rather confusing: When I see "Monad Sum", I might somehow expect that >>= would somehow, well, sum things up. But

foo = getSum $ do return 1 return 2 return 3 return 4

does not return 10

(At least you are not proposing a MonadPlus instance; that would be then really confusing.)

Greetings, Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Hi, Am Samstag, den 21.02.2015, 20:51 +0200 schrieb Oleg Grenrus:

As Sean pointed out there is already a thread about this issue. I agree with Erik’s opinion, https://mail.haskell.org/pipermail/libraries/2014-December/024509.html :

...

I'm +1 on the obviously useful instances (Data, Functor) and wouldn’t mind the others either, since I don't see any downsides.

Simple use case for Functor is e.g. fromIntegral <$> s

I have no doubts about Data, Functor, Foldable and Traversable. Data types like "Sum" have a clear container-like behavior. It’s Applicative and Monad that I’m unsure about. Greetings, Joachim -- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

Having Applicative might be nice for `pure`. That way we can getSum . foldMap pure, and so on. Of course, in that case using `Sum` is no different, but this opens up the ability to construct `Sum`s from other parts of code that simply require `Applicative`. On Sat, Feb 21, 2015 at 7:57 PM, Sean Leather wrote:

On Sat, Feb 21, 2015 at 8:51 PM, Oleg Grenrus wrote:

...

Sean, is there a trac ticket for this issue? I could make a patch early next week, as this seems to be discussed previously.

No, please create one. Also, you could put a patch on Phab and share both links here.

On Sat, Feb 21, 2015 at 9:44 PM, Joachim Breitner wrote:

...

It’s Applicative and Monad that I’m unsure about.

Good point. I'm also unsure. Do we need/want Applicative, Monad, and MonadFix instances that are analogues of Identity? Has anyone ever needed a Sum/Product/First/Last monad?

Regards, Sean

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

My point was that foldMap pure would happen somewhere entirely different - maybe in a library outside my control. Obviously that one line example doesn't quite communicate that though. If Sum is applicative, then I have the ability to just apply getSum, and have the Sum constructor automatically chosen for me. On 21 Feb 2015 21:48, "Joachim Breitner" wrote:

HI,

Am Samstag, den 21.02.2015, 21:26 +0000 schrieb Oliver Charles:

...

Having Applicative might be nice for `pure`. That way we can getSum . foldMap pure, and so on. Of course, in that case using `Sum` is no different, but this opens up the ability to construct `Sum`s from other parts of code that simply require `Applicative`.

is that any better than "getSum . foldMap Sum"?

Adding an Applicative instance, when the only main use case is to cover-over the lack of a Pointed type class, does not seem to be a good guiding principle.

BTW, coerce would work as well here, if you for some reason want to use a polymorphic argument to foldMap.

Still not convinced :-), Joachim

-- Joachim “nomeata” Breitner mail@joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata@joachim-breitner.de • GPG-Key: 0xF0FBF51F Debian Developer: nomeata@debian.org

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Am 22.02.2015 um 09:25 schrieb Edward Kmett:

I generally feel having these only-one-way-to-do-it instances just defined is better than forcing orphans upon those who _do_ want them.

Inevitably those users seem to wind up with separate orphans that tend to collide, or just give up and define their own type. Both of those outcomes are rather suboptimal.

I am generally opposed to adding instances just because there is one and only one way to write them. For me instances must also have some reasonable use. Every defined instance reduces the chance to find a silly error early. The question is: Is using the instance Monad Sum more likely to be useful or more likely to be an accident? I guess it is the second one. Then I would propose to use the known technique to write an instance that cannot be defined fully: https://ghc.haskell.org/trac/ghc/ticket/9334#comment:9 This way, programmers can achieve more confidence in their code and orphan instances are ruled out. I also think that it is easier to switch from an unimplementable instance to an implemented instance if someone finds a use, than to alter or remove an intentionally implemented instance.

Based on http://git.haskell.org/ghc.git/blob/refs/heads/ghc-7.10:/libraries/base/Data... http://git.haskell.org/ghc.git/blob/refs/heads/ghc-7.10:/libraries/base/Data... only First and Last have Functor, Applicative and Monad; Foldable, Traversable and Data are missing.

On 22 Feb 2015, at 09:56, Edward Kmett wrote:

Many instances for data types in Data.Monoid have already been added in 7.10.

Are these still missing?

-Edward

On Sat, Feb 21, 2015 at 10:34 AM, Oleg Grenrus mailto:oleg.grenrus@iki.fi> wrote: I propose to add Functor, Applicative, Monad, Foldable, and Traversable and maybe even MonadFix instances to wrapper newtypes in the Data.Monoid module. The same way as in the semigroups package, e.g. https://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-Semigroup.ht... https://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-Semigroup.ht... <https://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-Semigroup.ht... https://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-Semigroup.ht...>

Basically:

instance Functor Sum where fmap f (Sum x) = Sum (f x)

instance Foldable Sum where foldMap f (Sum a) = f a

instance Traversable Sum where traverse f (Sum a) = Sum <$> f a

instance Applicative Sum where pure = Sum a <* _ = a _ *> a = a Sum f <*> Sum x = Sum (f x)

instance Monad Sum where return = Sum _ >> a = a Sum a >>= f = f a

instance MonadFix Sum where mfix f = fix (f . getSum)

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Thanks! On Sun, Feb 22, 2015 at 7:40 AM, Oleg Grenrus wrote:

And there are the ticket and the patch:

https://ghc.haskell.org/trac/ghc/ticket/10107 https://phabricator.haskell.org/D673

...

On 22 Feb 2015, at 12:07, Oleg Grenrus wrote:

To clarify the discussion:

Let's add the following instances:

A: Functor, Foldable, Traversable to Sum, Product, Dual, First, and Last B: Data to everything in Data.Monoid (except Endo): Sum, Product, Dual, First and Last, All, Any, Alt C: Applicative, Monad, MonadFix to Sum, Product, Dual, First and Last D: Data to Identity

All seem to agree on A and B, C is "not sure", and D is new item.

- Oleg

...

On 21 Feb 2015, at 17:34, Oleg Grenrus wrote:

I propose to add Functor, Applicative, Monad, Foldable, and Traversable and maybe even MonadFix instances to wrapper newtypes in the Data.Monoid module. The same way as in the semigroups package, e.g. https://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-Semigroup.ht... < https://hackage.haskell.org/package/semigroups-0.16.1/docs/Data-Semigroup.ht...

...

Basically:

instance Functor Sum where fmap f (Sum x) = Sum (f x)

instance Foldable Sum where foldMap f (Sum a) = f a

instance Traversable Sum where traverse f (Sum a) = Sum <$> f a

instance Applicative Sum where pure = Sum a <* _ = a _ *> a = a Sum f <*> Sum x = Sum (f x)

instance Monad Sum where return = Sum _ >> a = a Sum a >>= f = f a

instance MonadFix Sum where mfix f = fix (f . getSum) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

+1 do all instances of the proposal. It is so common for me to want to use some polymorphic function but it not be available to me because it has a constraint not satisfied by a newtype wrapper around the type I want to use it with, so I have to write a bunch of boilerplate. I think we should eliminate such boilerplate aggressively. I even think Applicative and Monad would be useful. Just because a wrapper doesn't add behavior doesn't mean we should intentionally make it incompatible with so much code. On 5:07AM, Sun, Feb 22, 2015 Oleg Grenrus wrote:

To clarify the discussion:

Let's add the following instances:

A: Functor, Foldable, Traversable to Sum, Product, Dual, First, and Last B: Data to everything in Data.Monoid (except Endo): Sum, Product, Dual, First and Last, All, Any, Alt C: Applicative, Monad, MonadFix to Sum, Product, Dual, First and Last D: Data to Identity

All seem to agree on A and B, C is "not sure", and D is new item.

- Oleg

...

On 21 Feb 2015, at 17:34, Oleg Grenrus wrote:

I propose to add Functor, Applicative, Monad, Foldable, and Traversable and maybe even MonadFix instances to wrapper newtypes in the Data.Monoid module. The same way as in the semigroups package, e.g. https://hackage.haskell.org/package/semigroups-0.16.1/ docs/Data-Semigroup.html#t:Min <https://hackage.haskell.org/ package/semigroups-0.16.1/docs/Data-Semigroup.html#t:Min>

Basically:

instance Functor Sum where fmap f (Sum x) = Sum (f x)

instance Foldable Sum where foldMap f (Sum a) = f a

instance Traversable Sum where traverse f (Sum a) = Sum <$> f a

instance Applicative Sum where pure = Sum a <* _ = a _ *> a = a Sum f <*> Sum x = Sum (f x)

instance Monad Sum where return = Sum _ >> a = a Sum a >>= f = f a

instance MonadFix Sum where mfix f = fix (f . getSum) _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

On 2015-02-24 at 14:26, Joachim Breitner wrote:

Am Dienstag, den 24.02.2015, 14:00 +0000 schrieb Jake McArthur:

...

+1 do all instances of the proposal. It is so common for me to want to use some polymorphic function but it not be available to me because it has a constraint not satisfied by a newtype wrapper around the type I want to use it with, so I have to write a bunch of boilerplate. I think we should eliminate such boilerplate aggressively. I even think Applicative and Monad would be useful. Just because a wrapper doesn't add behavior doesn't mean we should intentionally make it incompatible with so much code.

your argument is valid: If I have a, say, "Num a", then I’d like to be able to (+) also on values of type "Sum a". Hence the instance Num a => Num (Sum a) and others of that kind (Eq, Ord, Read, Show).

But your argument does not apply to the question at hand. The "Monad Sum" instance is not of the „the instance of the wrapped thing lifted to the newtype wrapper“ kind (as the wrapped thing has kind * and thus is not a monad). Rather, it is the „there is only one only lawful Monad instance for Identity, and Sum is isomorphic to Identity, so let’s use it here“.

Applicative is convenient for defining such instances `(+) = liftA2 (+)` and for one-off use where the instance might be more confusing `atan2 <$> Sum 2 <*> Sum 3`. I'm not sure what I'd do with the Monad instance except where it's equivalent to Applicative. I still think it's useful for that, since it's often easier to read when the intermediate values are named. I'm +1 on all the proposed instances.