Can you provide a bit more detail on why you think (fmap . fmap) captures the concept behind (.) . (.) ?  It certainly does generalise it in one way - and I do get how, but is it the *right* generalisation? Or does it just coincide with (-> e)’s fmap being defined as (.), and in fact we would prefer to generalise the composition aspect, in which case Category would be a more ‘obvious’ place to look? On 17 August 2016 at 22:15:56, Tony Morris (tonymorris@gmail.com) wrote: You'd generalise it to: fmap . fmap :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) And then, would you do the same for Traversable, Foldable and Applicative? On 18/08/16 03:43, Alex Belanger wrote: Hi, Some of you might be familiar with (.:) = (.) . (.). It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d It allows the composition of two functions, the first one, accepting one operand, and the second, two operands. This appears to be a very common pattern, referenced a bit everywhere, almost always defined on lambdabot and found in multiple codebases in the wild. I'd like the know the general sentiment about this operator, as well as how its inclusion in base, probably Data.Function, would be perceived before I actually try to make it happen. Cheers, Alex (nitrix). _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Exactly! I'd be disappointed to see (.:) get enshrined in the base when it's such a special case: just one functor ((->) a), just one class (Functor), and just two levels deep. Once people learn the general patterns, they're easy to read & write and *much* more general & flexible. See http://conal.net/blog/posts/semantic-editor-combinators and the lens libraries. -- Conal On Wed, Aug 17, 2016 at 2:14 PM, Tony Morris wrote:

You'd generalise it to:

fmap . fmap :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b)

And then, would you do the same for Traversable, Foldable and Applicative?

On 18/08/16 03:43, Alex Belanger wrote:

Hi,

Some of you might be familiar with (.:) = (.) . (.).

It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d

It allows the composition of two functions, the first one, accepting one operand, and the second, two operands.

This appears to be a very common pattern, referenced a bit everywhere, almost always defined on lambdabot and found in multiple codebases in the wild.

I'd like the know the general sentiment about this operator, as well as how its inclusion in base, probably Data.Function, would be perceived before I actually try to make it happen.

Cheers, Alex (nitrix).

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Considering this would be in Data.Function along (.) and ($), I do not think generalizing it is the goal. The aim should be to keep it for functions only... or at least, that's how I've seen (.:) used so far. I'm all ears though. This is already getting interesting. On Wed, Aug 17, 2016 at 7:53 PM, MarLinn via Haskell-Cafe < haskell-cafe@haskell.org> wrote:

Some of you might be familiar with (.:) = (.) . (.).

It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d

First of all, I always called it "dot". Don't know where I picked that one up, though. (.:) looks like it could conflict with some lens or something. Would need checking.

Also, which version? This simple one? Or the Category one?

(.).(.) :: (Category cat) => cat c d -> (a -> cat b c) -> a -> cat b d

I know little about Category Theory, but throwing together some random words I collected over time that looks like... a "contravariant bind in the monad of endocategories", maybe? I just invented that and it's almost certainly meaningless gibberish, but knowing our community it might well be that *there's a lib for that*. Also, why is

h = f .: g == (f .) . g

not good enough?

So many questions, so much bikeshedding to do, so little time...

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Aeson (and cassava) use is very isolated. FWIW (.=) is in aeson (and other serialising libs) and lens, and do totally different things. I never needed both in the same module. Bikeshedding: if (.:) goes to base, why not also (.:.) and (.::) and … I’m -1, there is `composition` package [1], and I rather see base shrink, not grow. - Oleg - [1] http://hackage.haskell.org/package/composition-1.0.2.1/docs/Data-Composition... http://hackage.haskell.org/package/composition-1.0.2.1/docs/Data-Composition...

On 18 Aug 2016, at 07:22, Albert Y. C. Lai wrote:

(.:) is already used in both aeson and cassava. And not for (.) . (.)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.