Getting comonad into base

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

Getting comonad into base

Sandy Maguire
Hi all,

I frequently regret the lack of having the Comonad class in base. Are there any good reasons for its absence? If not, I can get started on a patch.

Best,
Sandy

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

Re: Getting comonad into base

Oliver Charles-3
Is this for instances of Comonad that you use, or so you can supply your own instances without a comonad dependency? I ask because I think I can recall a single time I actually had a use for comonad, and my understanding is that in Haskell comonads are relatively uninteresting - but it sounds like I'm mistaken!

On Fri, 11 Sep 2020, at 7:54 PM, Sandy Maguire wrote:
Hi all,
I frequently regret the lack of having the Comonad class in base. Are there any good reasons for its absence? If not, I can get started on a patch.
Best,
Sandy
_______________________________________________
Libraries mailing list


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

Re: Getting comonad into base

chessai .
In reply to this post by Sandy Maguire
Hi Sandy,

I think this would be a good candidate for the new Libraries Proposal process, modelled after ghc-proposals. See https://github.com/haskell-core/core-libraries-proposals

I recommend writing a proposal there. In particular, for changes like this, one of the things that needs the most thought is the story around a migration path.

Hope this helps.

Thanks

On Fri, Sep 11, 2020, 13:55 Sandy Maguire <[hidden email]> wrote:
Hi all,

I frequently regret the lack of having the Comonad class in base. Are there any good reasons for its absence? If not, I can get started on a patch.

Best,
Sandy
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Getting comonad into base

Sandy Maguire
Ollie: It's for giving my own instances. I suspect most of the reasons that comonads feel uninteresting is that they've been relegated to a second-class citizen in the ecosystem.

chessai: I'm not proposing the whole package; just the class. I can't imagine the migration path is any harder than putting an ifdef into the comonads package.

On Fri, Sep 11, 2020 at 12:06 PM chessai <[hidden email]> wrote:
Hi Sandy,

I think this would be a good candidate for the new Libraries Proposal process, modelled after ghc-proposals. See https://github.com/haskell-core/core-libraries-proposals

I recommend writing a proposal there. In particular, for changes like this, one of the things that needs the most thought is the story around a migration path.

Hope this helps.

Thanks

On Fri, Sep 11, 2020, 13:55 Sandy Maguire <[hidden email]> wrote:
Hi all,

I frequently regret the lack of having the Comonad class in base. Are there any good reasons for its absence? If not, I can get started on a patch.

Best,
Sandy
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

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

Re: Getting comonad into base

chessai .
Sorry, I still have semigroupoids on my mind. There's no renaming like with Foldable1, so yes the migration path is not more complicated than what you say.

I still think a proposal is worthwhile because many people (including myself) fail to see motivation for comonads in every day programming. The fact that Ollie, an experienced haskell programmer, also shares this sentiment makes me more certain that people need motivating. I think a proposal is a good way to do that.

On Fri, Sep 11, 2020, 14:16 Sandy Maguire <[hidden email]> wrote:
Ollie: It's for giving my own instances. I suspect most of the reasons that comonads feel uninteresting is that they've been relegated to a second-class citizen in the ecosystem.

chessai: I'm not proposing the whole package; just the class. I can't imagine the migration path is any harder than putting an ifdef into the comonads package.

On Fri, Sep 11, 2020 at 12:06 PM chessai <[hidden email]> wrote:
Hi Sandy,

I think this would be a good candidate for the new Libraries Proposal process, modelled after ghc-proposals. See https://github.com/haskell-core/core-libraries-proposals

I recommend writing a proposal there. In particular, for changes like this, one of the things that needs the most thought is the story around a migration path.

Hope this helps.

Thanks

On Fri, Sep 11, 2020, 13:55 Sandy Maguire <[hidden email]> wrote:
Hi all,

I frequently regret the lack of having the Comonad class in base. Are there any good reasons for its absence? If not, I can get started on a patch.

Best,
Sandy
_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries