
Let's add <&> to Data.Functor then, as there is a reasonably clear consensus and it already sees fairly wide-spread use. I think we should leave ffor to another day and a separate explicit request / discussion, unless someone else on the CLC really wants to pipe up strongly in favor of adding it today. Adding the CLC to the distribution list to hammer out that detail. -Edward On Fri, Mar 10, 2017 at 1:12 AM, Siddhanathan Shanmugam < siddhanathan+eml@gmail.com> wrote:
There hasn't been any activity in this thread for two weeks. Summary of the discussion so far:
+4 in favor +1 weakly in favor -1 for not being accompanied by ffor
I'll let the committee take over.
On Wed, Feb 22, 2017 at 8:57 PM, Elliot Cameron
wrote: Heh, I suppose that doesn't help my case much, does it? I "derived" the name for my own uses many times prior to seeing it elsewhere (most notably Reflex: http://hackage.haskell.org/package/reflex/docs/ Reflex-Class.html#v:ffor). Like I said, the name "ffor" isn't wildly important IMO. I don't want to start the "fmap should be map" debate all over again either.
On Wed, Feb 22, 2017 at 11:51 PM, John Wiegley
wrote: >> "EC" == Elliot Cameron
writes: EC> FWIW, I'm less concerned about the precise name of ffor, although it seems EC> sad to to lose the obvious correlation with fmap.
Ah, it wasn't until you said that that I understood why "ffor", but now it makes some sense. :)
-- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries