[Proposal] Add instance Monoid a => Monoid (Const a b)

newer
"Elvis" operator (?:) as a reverse...

older
Re: [Proposal] Renaming (:=:) to...

haskell＠nand.wakku.to

29 Sep 2013 29 Sep '13

12:01 p.m.

Hello, I think this a Monoid instance on Const would be useful. The motivation comes from ‘lens’, where folds come out as (a -> Const a a) -> s -> Const a s. This instance, together with the Monoid a => Monoid (r -> a) instance, allows folds themselves to be an instance of Monoid, allowing for some really pretty code. Example of the instance body:

...

instance Monoid a => Monoid (Const a b) where mempty = Const mempty mappend (Const a) (Const b) = Const (mappend a b)

Examples of it being used together with lens:

...

...
...
"Hello, world!" ^.. mconcat [ix 2, ix 7, ix 1] "lwe"

Discussion Period: 2 weeks

Show replies by date

Edward Kmett

29 Sep 29 Sep

12:13 p.m.

A decent argument in favor is there really isn't another viable instance for it. Being able to glue together folds with (<>) never occurred to me. +1 from me -Edward On Sun, Sep 29, 2013 at 12:01 PM, wrote:

...

Hello,

I think this a Monoid instance on Const would be useful. The motivation comes from ‘lens’, where folds come out as (a -> Const a a) -> s -> Const a s. This instance, together with the Monoid a => Monoid (r -> a) instance, allows folds themselves to be an instance of Monoid, allowing for some really pretty code.

Example of the instance body:

...
instance Monoid a => Monoid (Const a b) where mempty = Const mempty mappend (Const a) (Const b) = Const (mappend a b)

Examples of it being used together with lens:

...
...
...
"Hello, world!" ^.. mconcat [ix 2, ix 7, ix 1] "lwe"

Discussion Period: 2 weeks _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Dag Odenhall

2:12 p.m.

Cute trick; I've been wanting a way to get a product out of a set of folds. +1 On Sun, Sep 29, 2013 at 6:13 PM, Edward Kmett wrote:

...

A decent argument in favor is there really isn't another viable instance for it. Being able to glue together folds with (<>) never occurred to me.

+1 from me

-Edward

On Sun, Sep 29, 2013 at 12:01 PM, wrote:

...
Hello,

I think this a Monoid instance on Const would be useful. The motivation comes from ‘lens’, where folds come out as (a -> Const a a) -> s -> Const a s. This instance, together with the Monoid a => Monoid (r -> a) instance, allows folds themselves to be an instance of Monoid, allowing for some really pretty code.

Example of the instance body:

...
instance Monoid a => Monoid (Const a b) where mempty = Const mempty mappend (Const a) (Const b) = Const (mappend a b)

Examples of it being used together with lens:

...
...
...
"Hello, world!" ^.. mconcat [ix 2, ix 7, ix 1] "lwe"

Discussion Period: 2 weeks _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Ross Paterson

12 Oct 12 Oct

4:37 a.m.

On Sun, Sep 29, 2013 at 12:13:34PM -0400, Edward Kmett wrote:

...

A decent argument in favor is there really isn't another viable instance for it. Being able to glue together folds with (<>) never occurred to me.

I agree with that. The only issue is that that we have two functors that are identical: - Const exported by Control.Applicative in base - Constant exported by Data.Functor.Constant in transformers We should decide on a single name, and which package it should be in.

Edward Kmett

1:32 p.m.

I am strongly in favor of removing Constant from transformers. It isn't used by the vast majority of the ecosystem, but Const is in very active use. The only major consumer of Constant at this time I think is Rusell O'Connor's multiplate library. On a related note Simon recently asked the core libraries committee if we should move Data.Functor.Identity into base. I'm very strongly inclined to say yes, as was the rest of the committee. Do you have any objection there? Between moving Identity into base and removing Constant it would mean that transformers would then only have to contain ...well.. transformers. =) -Edward On Sat, Oct 12, 2013 at 4:37 AM, Ross Paterson wrote:

...

On Sun, Sep 29, 2013 at 12:13:34PM -0400, Edward Kmett wrote:

...
A decent argument in favor is there really isn't another viable instance for it. Being able to glue together folds with (<>) never occurred to me.

I agree with that. The only issue is that that we have two functors that are identical:

- Const exported by Control.Applicative in base - Constant exported by Data.Functor.Constant in transformers

We should decide on a single name, and which package it should be in. _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Gershom Bazerman

1:57 p.m.

On 10/12/13 1:32 PM, Edward Kmett wrote:

...

Between moving Identity into base and removing Constant it would mean that transformers would then only have to contain ...well.. transformers. =)

-Edward

Well, not quite. Compose should migrate into base at well at some point, I think. Especially since currently we have traversable laws in base using a datatype _not_ in base! I can see an argument in favor of Product as well, but also an argument, perhaps, that the product of two functors is somewhat less common than their composition. I consider the whole "polynomial functor toolkit" as pretty basic. But I can see a slippery-slope danger that we should only bring in those components that make other "basic" parts of base more elegant. Also, we should bear in mind that "growing" the algebraic part of base (Traversable, Functors, etc.) doesn't necessarily go against the spirit of then taking these slightly larger units of conceptual functionality and splitting them out from "core-base" in the next go-round. --Gershom

Edward Kmett

2:30 p.m.

That is a pretty solid argument for moving Compose. Especially as Traversable will be transitioning into the Prelude in 7.10. -Edward On Sat, Oct 12, 2013 at 1:57 PM, Gershom Bazerman wrote:

...

On 10/12/13 1:32 PM, Edward Kmett wrote:

...
Between moving Identity into base and removing Constant it would mean that transformers would then only have to contain ...well.. transformers. =)

-Edward

Well, not quite. Compose should migrate into base at well at some point,

I think. Especially since currently we have traversable laws in base using a datatype _not_ in base!

I can see an argument in favor of Product as well, but also an argument, perhaps, that the product of two functors is somewhat less common than their composition.

I consider the whole "polynomial functor toolkit" as pretty basic. But I can see a slippery-slope danger that we should only bring in those components that make other "basic" parts of base more elegant.

Also, we should bear in mind that "growing" the algebraic part of base (Traversable, Functors, etc.) doesn't necessarily go against the spirit of then taking these slightly larger units of conceptual functionality and splitting them out from "core-base" in the next go-round.

--Gershom

______________________________**_________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/**mailman/listinfo/libraries http://www.haskell.org/mailman/listinfo/libraries

Ross Paterson

3:15 p.m.

On Sat, Oct 12, 2013 at 01:32:33PM -0400, Edward Kmett wrote:

...

I am strongly in favor of removing Constant from transformers.

No objection to that: we obviously don't need both.

...

It isn't used by the vast majority of the ecosystem, but Const is in very active use.

The only major consumer of Constant at this time I think is Rusell O'Connor's multiplate library.

And presumably you want to keep the shorter name for backward compatibility.

...

On a related note Simon recently asked the core libraries committee if we should move Data.Functor.Identity into base.

I'm very strongly inclined to say yes, as was the rest of the committee. Do you have any objection there?

I don't object to moving Data.Functor.Identity, but I wish that discussion had happened in a place where the rest of us could see it. On this tangent, I note on http://www.haskell.org/haskellwiki/Core_Libraries_Committee that the process is described as: It is expected the committee will discuss any matters brought to it amongst themselves, and if they think appropriate, with the wider community, to try to reach consensus. Ultimately, the committee will make decisions by more than half of the membership voting for a particular outcome. These rules of operation may also be changed in the same way. That's a more closed model than I thought was envisaged when the committee was set up, and I think it's problematic. I'd suggest that open discussion with the committee making the final decision is likely to produce better results.

Edward A Kmett

6:16 p.m.

...

On Oct 12, 2013, at 3:15 PM, Ross Paterson wrote:

...
On Sat, Oct 12, 2013 at 01:32:33PM -0400, Edward Kmett wrote: I am strongly in favor of removing Constant from transformers.

No objection to that: we obviously don't need both.

...
It isn't used by the vast majority of the ecosystem, but Const is in very active use.

The only major consumer of Constant at this time I think is Rusell O'Connor's multiplate library.

And presumably you want to keep the shorter name for backward compatibility.

Yep.

...

...
On a related note Simon recently asked the core libraries committee if we should move Data.Functor.Identity into base.

I'm very strongly inclined to say yes, as was the rest of the committee. Do you have any objection there?

I don't object to moving Data.Functor.Identity, but I wish that discussion had happened in a place where the rest of us could see it. On this tangent, I note on

http://www.haskell.org/haskellwiki/Core_Libraries_Committee

that the process is described as:

It is expected the committee will discuss any matters brought to it amongst themselves, and if they think appropriate, with the wider community, to try to reach consensus. Ultimately, the committee will make decisions by more than half of the membership voting for a particular outcome. These rules of operation may also be changed in the same way.

That's a more closed model than I thought was envisaged when the committee was set up, and I think it's problematic. I'd suggest that open discussion with the committee making the final decision is likely to produce better results.

We're trying to carry out most conversations here on libraries@ This was literally just a question posed directly to that mailing list by Simon the other day seeking feedback in advance of his talk and a couple of short replies from folks thinking it'd be a good idea. Not a formal proposal. I agree it really probably belongs out here, it was just something I felt I should mention while we were on a related topic. I'm happy to turn it into a more formal proposal with a capital P.

...

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Dag Odenhall

3:40 p.m.

On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett wrote: On a related note Simon recently asked the core libraries committee if we

...

should move Data.Functor.Identity into base.

How about calling that one Id then (already in Data.Traversable but not exported). This would be more consistent with Const not being called Constant. Maybe also put it in Control.Applicative or move both somewhere better. For back-compat, transformers could continue to export those modules, with aliases like type Identity = Id.

Stijn van Drongelen

3:48 p.m.

On Oct 12, 2013 9:41 PM, "Dag Odenhall" wrote:

...

On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett wrote:

...
On a related note Simon recently asked the core libraries committee if

we should move Data.Functor.Identity into base.

...

How about calling that one Id then (already in Data.Traversable but not

exported). This would be more consistent with Const not being called Constant. Maybe also put it in Control.Applicative or move both somewhere better.

...

For back-compat, transformers could continue to export those modules,

with aliases like type Identity = Id.

...

I strongly agree with this. It would also preserve the 'symmetry' with value-level const and id, perhaps even making the concept more accessible to beginners.

Dan Burton

4:50 p.m.

The back-compat can't replace code that uses the `Identity` data constructor, though. It will also make existing code bases ambiguous if they have defined their own `Id` data constructor. Pretty easy fixes, but nontrivial, so worth noting. Despite the pain involved, I think that Identity -> Id when moving this functor into base is a good choice. -- Dan Burton On Sat, Oct 12, 2013 at 12:40 PM, Dag Odenhall wrote:

...

On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett wrote:

On a related note Simon recently asked the core libraries committee if we

...
should move Data.Functor.Identity into base.

How about calling that one Id then (already in Data.Traversable but not exported). This would be more consistent with Const not being called Constant. Maybe also put it in Control.Applicative or move both somewhere better.

For back-compat, transformers could continue to export those modules, with aliases like type Identity = Id.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Edward A Kmett

6:27 p.m.

There are those of us who need to maintain code that works on platforms older than GHC HEAD. This would make it impossible to keep an API working across the change. -Edward

...

On Oct 12, 2013, at 4:50 PM, Dan Burton wrote:

The back-compat can't replace code that uses the `Identity` data constructor, though. It will also make existing code bases ambiguous if they have defined their own `Id` data constructor. Pretty easy fixes, but nontrivial, so worth noting. Despite the pain involved, I think that Identity -> Id when moving this functor into base is a good choice.

-- Dan Burton

...
On Sat, Oct 12, 2013 at 12:40 PM, Dag Odenhall wrote:

...
On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett wrote:

On a related note Simon recently asked the core libraries committee if we should move Data.Functor.Identity into base.

How about calling that one Id then (already in Data.Traversable but not exported). This would be more consistent with Const not being called Constant. Maybe also put it in Control.Applicative or move both somewhere better.

For back-compat, transformers could continue to export those modules, with aliases like type Identity = Id.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Michael Snoyman

13 Oct 13 Oct

12:16 a.m.

I agree with Edward here. I don't see enough value in the name change to warrant all the breakage and conditional compilation hacks that will ensue. On Sunday, October 13, 2013, Edward A Kmett wrote:

...

There are those of us who need to maintain code that works on platforms older than GHC HEAD.

This would make it impossible to keep an API working across the change.

-Edward

On Oct 12, 2013, at 4:50 PM, Dan Burton > wrote:

The back-compat can't replace code that uses the `Identity` data constructor, though. It will also make existing code bases ambiguous if they have defined their own `Id` data constructor. Pretty easy fixes, but nontrivial, so worth noting. Despite the pain involved, I think that Identity -> Id when moving this functor into base is a good choice.

-- Dan Burton

On Sat, Oct 12, 2013 at 12:40 PM, Dag Odenhall

...
wrote:

...
On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett > wrote:

On a related note Simon recently asked the core libraries committee if we

...
should move Data.Functor.Identity into base.

How about calling that one Id then (already in Data.Traversable but not exported). This would be more consistent with Const not being called Constant. Maybe also put it in Control.Applicative or move both somewhere better.

For back-compat, transformers could continue to export those modules, with aliases like type Identity = Id.

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

John Wiegley

30 Sep 30 Sep

12:58 p.m.

...

...
...
...
...
haskell writes:

...

I think this a Monoid instance on Const would be useful.

+1 -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net

Krzysztof Gogolewski

12:59 p.m.

...

...
I think this a Monoid instance on Const would be useful. +1

2013/9/30 John Wiegley :

...

...
...
...
...
...
haskell writes:

...
I think this a Monoid instance on Const would be useful.

+1

-- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

Herbert Valerio Riedel

5 Oct 5 Oct

10:48 a.m.

On 2013-09-29 at 18:01:23 +0200, haskell@nand.wakku.to wrote: [...]

...

...
instance Monoid a => Monoid (Const a b) where mempty = Const mempty mappend (Const a) (Const b) = Const (mappend a b)

+1 from me PS: As this proposal seems to be non-controversial so far, I've already added the instance in the soon-to-be `base-4.7.0.0`. Therefore, unless objections to this proposal should be voiced, this instance will be part of GHC 7.8.1's `base-4.7.0.0`. Cheers, hvr

4237

Age (days ago)

4251

Last active (days ago)

List overview

Download

16 comments

12 participants

participants (12)

Dag Odenhall
Dan Burton
Edward A Kmett
Edward Kmett
Gershom Bazerman
haskell＠nand.wakku.to
Herbert Valerio Riedel
John Wiegley
Krzysztof Gogolewski
Michael Snoyman
Ross Paterson
Stijn van Drongelen