<div dir="ltr"><div>As part of GHC 7.10 we moved <font face="monospace, monospace">Data.Functor.Identity</font> from <font face="monospace, monospace">transformers</font> into <font face="monospace, monospace">base</font>. (We'd previously had a private, equivalent definition buried in <font face="monospace, monospace">Data.Traversable</font> that we didn't export.)</div><div><br></div>In a similar vein, I hereby propose moving <font face="monospace, monospace">Data.Functor.Sum</font>, <font face="monospace, monospace">Data.Functor.Product</font>, <font face="monospace, monospace">Data.Functor.Compose</font>, and <font face="monospace, monospace">Data.Functor.Classes</font> into base as they exist in <font face="monospace, monospace">transformers</font>, without unduly bikeshedding their APIs.<div><br></div><div><div>This would effectively reduce the role of <font face="monospace, monospace">transformers</font> to simply supplying actual transformers and continue the general pattern of universal constructions migrating into <font face="monospace, monospace">base</font>. Without bikeshedding their implementations this migration becomes a no-op for existing users.</div><div><br></div><div>The most awkward of these is the <font face="monospace, monospace">Data.Functor.Classes</font> 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 <font face="monospace, monospace">transformers</font> for which a <font face="monospace, monospace">base</font>-based version of the API could exploit <font face="monospace, monospace">DefaultSignatures</font> to ease migration.</div><div><br></div><div>I'm rather deliberately not including <font face="monospace, monospace">Data.Functor.Constant</font> in this proposal as when it has been discussed in the past, <font face="monospace, monospace">Const</font> from <font face="monospace, monospace">Control.Applicative</font> has effectively grown to subsume that role. That said, we if we bring in the rest of this stuff we could migrate it to <font face="monospace, monospace">Data.Functor.Const</font> and simply re-export it from <font face="monospace, monospace">Control.Applicative</font> to avoid breakage.</div><div><br></div><div>So, as a concrete proposal I propose that we:</div><div><br></div><div>1.) Move <font face="monospace, monospace">Data.Functor.Sum</font>, <font face="monospace, monospace">Data.Functor.Product</font>, <font face="monospace, monospace">Data.Functor.Compose</font> and <font face="monospace, monospace">Data.Functor.Classes</font> into <font face="monospace, monospace">base</font>.</div><div><br></div><div>2.) Move <font face="monospace, monospace">Control.Applicative</font><font face="arial, helvetica, sans-serif">'s </font><font face="monospace, monospace">Const</font> into <font face="monospace, monospace">Data.Functor.Const</font>, but continue to re-export it from <font face="monospace, monospace">Control.Applicative</font>.</div><div><br></div><div>3.) Add whatever missing, sensible, instances make sense after the transition that were ruled out by these modules' previous placement. <i>e.g.</i> <font face="monospace, monospace">Data</font>, <font face="monospace, monospace">Generic</font>, <font face="monospace, monospace">Generic1.</font></div><div><br></div><div>Discussion Period: 2 weeks</div><div><br></div><div>-Edward Kmett</div></div></div>