Proposal: Migrate Data.Functor.{Sum, Product, Compose} from transformers to base.

[Edward Kmett]

The fix is to remove the one from transformers, nobody uses the thing.
Hence why it was decidedly not included in this proposal.

-Edward

On Thu, Jul 23, 2015 at 7:39 PM, David Feuer <david.feuer at gmail.com> wrote:

> 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" <ekmett at gmail.com> 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 at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150723/6cef317d/attachment.html>