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

[Edward Kmett]

I think I'd like to consider that a separate proposal and let it succeed or
fail on its own merits.

-Edward

On Thu, Jul 23, 2015 at 8:30 PM, Michael Snoyman <michael at snoyman.com>
wrote:

> 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 <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/cf9b66f3/attachment-0001.html>