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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Niklas Haas
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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, <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Dag Odenhall

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 <[hidden email]> 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, <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

John Wiegley-3
In reply to this post by Niklas Haas
>>>>> haskell  <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

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

2013/9/30 John Wiegley <[hidden email]>:

>>>>>> haskell  <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Herbert Valerio Riedel
In reply to this post by Niklas Haas
On 2013-09-29 at 18:01:23 +0200, [hidden email] 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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Ross Paterson-2
In reply to this post by Edward Kmett-2
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Gershom Bazerman
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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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 <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Ross Paterson-2
In reply to this post by Edward Kmett-2
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.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Dag Odenhall
In reply to this post by Edward Kmett-2

On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Stijn van Drongelen


On Oct 12, 2013 9:41 PM, "Dag Odenhall" <[hidden email]> wrote:
>
> On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <[hidden email]> 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.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Dan Burton
In reply to this post by Dag Odenhall
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 <[hidden email]> wrote:

On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
In reply to this post by Ross Paterson-2


> On Oct 12, 2013, at 3:15 PM, Ross Paterson <[hidden email]> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
In reply to this post by Dan Burton
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 <[hidden email]> 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 <[hidden email]> wrote:

On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <[hidden email]> 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
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

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

Michael Snoyman
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 <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;danburton.email@gmail.com&#39;);" target="_blank">danburton.email@...> 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 <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;dag.odenhall@gmail.com&#39;);" target="_blank">dag.odenhall@...> wrote:

On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <<a href="javascript:_e({}, &#39;cvml&#39;, &#39;ekmett@gmail.com&#39;);" target="_blank">ekmett@...> 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
<a href="javascript:_e({}, &#39;cvml&#39;, &#39;Libraries@haskell.org&#39;);" target="_blank">Libraries@...
http://www.haskell.org/mailman/listinfo/libraries



_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries