[Proposal] Add instance Monoid a => Monoid (Const a b)
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
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, <haskell@nand.wakku.to> 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
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 <ekmett@gmail.com> 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, <haskell@nand.wakku.to> 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
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.
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 <R.Paterson@city.ac.uk>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
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
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 <gershomb@gmail.com>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>
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.
On Oct 12, 2013, at 3:15 PM, Ross Paterson <R.Paterson@city.ac.uk> 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
On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <ekmett@gmail.com> 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.
On Oct 12, 2013 9:41 PM, "Dag Odenhall" <dag.odenhall@gmail.com> wrote:
On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <ekmett@gmail.com> 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.
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 <dag.odenhall@gmail.com>wrote:
On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <ekmett@gmail.com> 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
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 <danburton.email@gmail.com> 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 <dag.odenhall@gmail.com> wrote:
On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <ekmett@gmail.com> 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
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 <danburton.email@gmail.com<javascript:_e({}, 'cvml', 'danburton.email@gmail.com');>> 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 <dag.odenhall@gmail.com<javascript:_e({}, 'cvml', 'dag.odenhall@gmail.com');>
wrote:
On Sat, Oct 12, 2013 at 7:32 PM, Edward Kmett <ekmett@gmail.com<javascript:_e({}, 'cvml', 'ekmett@gmail.com');>> 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 <javascript:_e({}, 'cvml', 'Libraries@haskell.org');> http://www.haskell.org/mailman/listinfo/libraries
I think this a Monoid instance on Const would be useful. +1
2013/9/30 John Wiegley <johnw@fpcomplete.com>:
haskell <haskell@nand.wakku.to> 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
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
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