The biggest problem with Constant is the bloody name. The one from transformers is called Constant, while the one in Control.Applicative is called Const, so they are incompatible. I have no idea how to fix that. On Jul 23, 2015 7:18 PM, "Edward Kmett" wrote:

As part of GHC 7.10 we moved Data.Functor.Identity from transformers into base. (We'd previously had a private, equivalent definition buried in Data.Traversable that we didn't export.)

In a similar vein, I hereby propose moving Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into base as they exist in transformers, without unduly bikeshedding their APIs.

This would effectively reduce the role of transformers to simply supplying actual transformers and continue the general pattern of universal constructions migrating into base. Without bikeshedding their implementations this migration becomes a no-op for existing users.

The most awkward of these is the Data.Functor.Classes API, but it affects a number of their instances, and without it, those instances would have to be orphans, so my gut reaction would be to say yes, we should move that as well. There are also some in-flight API changes in the works in the HEAD version of transformers for which a base-based version of the API could exploit DefaultSignatures to ease migration.

I'm rather deliberately not including Data.Functor.Constant in this proposal as when it has been discussed in the past, Const from Control.Applicative has effectively grown to subsume that role. That said, we if we bring in the rest of this stuff we could migrate it to Data.Functor.Const and simply re-export it from Control.Applicative to avoid breakage.

So, as a concrete proposal I propose that we:

1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and Data.Functor.Classes into base.

2.) Move Control.Applicative's Const into Data.Functor.Const, but continue to re-export it from Control.Applicative.

3.) Add whatever missing, sensible, instances make sense after the transition that were ruled out by these modules' previous placement. *e.g.* Data, Generic, Generic1.

Discussion Period: 2 weeks

-Edward Kmett

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

This sounds reasonable, +1. I notice that there was also mention earlier today about MonadIO, and that it was not mentioned in this email. Does that mean that a separate proposal may be coming? On Thu, Jul 23, 2015 at 4:18 PM Edward Kmett wrote:

As part of GHC 7.10 we moved Data.Functor.Identity from transformers into base. (We'd previously had a private, equivalent definition buried in Data.Traversable that we didn't export.)

In a similar vein, I hereby propose moving Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose, and Data.Functor.Classes into base as they exist in transformers, without unduly bikeshedding their APIs.

This would effectively reduce the role of transformers to simply supplying actual transformers and continue the general pattern of universal constructions migrating into base. Without bikeshedding their implementations this migration becomes a no-op for existing users.

The most awkward of these is the Data.Functor.Classes API, but it affects a number of their instances, and without it, those instances would have to be orphans, so my gut reaction would be to say yes, we should move that as well. There are also some in-flight API changes in the works in the HEAD version of transformers for which a base-based version of the API could exploit DefaultSignatures to ease migration.

I'm rather deliberately not including Data.Functor.Constant in this proposal as when it has been discussed in the past, Const from Control.Applicative has effectively grown to subsume that role. That said, we if we bring in the rest of this stuff we could migrate it to Data.Functor.Const and simply re-export it from Control.Applicative to avoid breakage.

So, as a concrete proposal I propose that we:

1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and Data.Functor.Classes into base.

2.) Move Control.Applicative's Const into Data.Functor.Const, but continue to re-export it from Control.Applicative.

3.) Add whatever missing, sensible, instances make sense after the transition that were ruled out by these modules' previous placement. *e.g.* Data, Generic, Generic1.

Discussion Period: 2 weeks

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

On 07/23/2015 07:18 PM, Edward Kmett wrote:

... So, as a concrete proposal I propose that we:

1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and Data.Functor.Classes into base.

2.) Move Control.Applicative's Const into Data.Functor.Const, but continue to re-export it from Control.Applicative.

3.) Add whatever missing, sensible, instances make sense after the transition that were ruled out by these modules' previous placement. /e.g./ Data, Generic, Generic1.

+1 to all three parts

On 2015-07-24 at 01:18:15 +0200, Edward Kmett wrote: [...]

So, as a concrete proposal I propose that we:

1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and Data.Functor.Classes into base.

2.) Move Control.Applicative's Const into Data.Functor.Const, but continue to re-export it from Control.Applicative.

3.) Add whatever missing, sensible, instances make sense after the transition that were ruled out by these modules' previous placement. *e.g.* Data, Generic, Generic1.

Discussion Period: 2 weeks

+1

On 23/07/2015, Edward Kmett wrote:

So, as a concrete proposal I propose that we:

1.) Move Data.Functor.Sum, Data.Functor.Product, Data.Functor.Compose and Data.Functor.Classes into base.

2.) Move Control.Applicative's Const into Data.Functor.Const, but continue to re-export it from Control.Applicative.

3.) Add whatever missing, sensible, instances make sense after the transition that were ruled out by these modules' previous placement. *e.g.* Data, Generic, Generic1.

+1 all