How can I understand "(.) . (.)"?

Question

I believe I understand fmap . fmap for Functors, but on functions it's hurting my head for months now.

I've seen that you can just apply the definition of (.) to (.) . (.), but I've forgot how to do that.
When I try it myself it always turns out wrong:

(.) f g = \x -> f (g x)
(.) (.) (.) = \x -> (.) ((.) x)
\x f -> (.) ((.) x) f
\x f y  -> (((.)(f y)) x)
\x f y g-> (((.)(f y) g) x)
\x f y g-> ((f (g y)) x)
\x f y g-> ((f (g y)) x):: t2 -> (t1 -> t2 -> t) -> t3 -> (t3 -> t1) -> t

If "just applying the definition" is the only way of doing it, how did anybody come up with (.) . (.)?
There must be some deeper understanding or intuition I'm missing.

Answer 1

You can also use your understanding of fmap . fmap.

If you have two Functors foo and bar, then

fmap . fmap :: (a -> b)  ->  foo (bar a)    ->   foo (bar b)

fmap . fmap takes a function and produces an induced function for the composition of the two Functors.

Now, for any type t, (->) t is a Functor, and the fmap for that Functor is (.).

So (.) . (.) is fmap . fmap for the case where the two Functors are (->) s and (->) t, and thus

(.) . (.) :: (a -> b) -> ((->) s) ((->) t a) -> ((->) s) ((->) t b)
          =  (a -> b) -> (s -> (t -> a))     -> (s -> (t -> b))
          =  (a -> b) -> (s ->  t -> a )     -> (s ->  t -> b )

it "composes" a function f :: a -> b with a function of two arguments, g :: s -> t -> a,

((.) . (.)) f g = \x y -> f (g x y)

That view also makes it clear that, and how, the pattern extends to functions taking more arguments,

(.)             :: (a -> b) -> (s ->           a) -> (s ->           b)
(.) . (.)       :: (a -> b) -> (s -> t ->      a) -> (s -> t ->      b)
(.) . (.) . (.) :: (a -> b) -> (s -> t -> u -> a) -> (s -> t -> u -> b)

etc.

Answer 2

Coming up with (.) . (.) is actually pretty straightforward, it's the intuition behind what it does that is quite tricky to understand.

(.) gets you very far when rewriting expression into the "pipe" style computations (think of | in shell). However, it becomes awkward to use once you try to compose a function that takes multiple arguments with a function that only takes one. As an example, let's have a definition of concatMap:

concatMap :: (a -> [b]) -> [a] -> [b]
concatMap f xs = concat (map f xs)

Getting rid of xs is just a standard operation:

concatMap f = concat . map f

However, there's no "nice" way of getting rid of f. This is caused by the fact, that map takes two arguments and we'd like to apply concat on its final result.

You can of course apply some pointfree tricks and get away with just (.):

concatMap f = (.) concat (map f)
concatMap f = (.) concat . map $ f
concatMap = (.) concat . map
concatMap = (concat .) . map

But alas, readability of this code is mostly gone. Instead, we introduce a new combinator, that does exactly what we need: apply the second function to the final result of first one.

-- .: is fairly standard name for this combinator
(.:) :: (c -> d) -> (a -> b -> c) -> a -> b -> d
(f .: g) x y = f (g x y)

concatMap = concat .: map

Fine, that's it for motivation. Let's get to the pointfree business.

(.:) = \f g x y -> f (g x y)
     = \f g x y -> f ((g x) y)
     = \f g x y -> f . g x $ y
     = \f g x   -> f . g x

Now, here comes the interesting part. This is yet another of the pointfree tricks that usually helps when you get stuck: we rewrite . into its prefix form and try to continue from there.

     = \f g x   -> (.) f (g x)
     = \f g x   -> (.) f . g $ x
     = \f g     -> (.) f . g
     = \f g     -> (.) ((.) f) g
     = \f       -> (.) ((.) f)
     = \f       -> (.) . (.) $ f
     =             (.) . (.)

As for intuition, there's this very nice article that you should read. I'll paraphrase the part about (.):

Let's think again about what our combinator should do: it should apply f to the result of result of g (I've been using final result in the part before on purpose, it's really what you get when you fully apply - modulo unifying type variables with another function type - the g function, result here is just application g x for some x).

What it means for us to apply f to the result of g? Well, once we apply g to some value, we'll take the result and apply f to it. Sounds familiar: that's what (.) does.

result :: (b -> c) -> ((a -> b) -> (a -> c))
result = (.)

Now, it turns out that composition (our of word) of those combinators is just a function composition, that is:

(.:) = result . result -- the result of result

Answer 3

Your solution diverges when you introduce y. It should be

\x f y -> ((.) ((.) x) f) y     :: (c -> d) -> (a -> b -> c) -> a -> b -> d
\x f y z -> ((.) ((.) x) f) y z :: (c -> d) -> (a -> b -> c) -> a -> b -> d
\x f y z -> ((.) x (f y)) z     :: (c -> d) -> (a -> b -> c) -> a -> b -> d
-- Or alternately:
\x f y z -> (x . f y) z         :: (c -> d) -> (a -> b -> c) -> a -> b -> d
\x f y z -> (x (f y z))         :: (c -> d) -> (a -> b -> c) -> a -> b -> d

Which matches the original type signature: (.) . (.) :: (c -> d) -> (a -> b -> c) -> a -> b -> d

(It's easiest to do the expansion in ghci, where you can check each step with :t expression)

Edit:

The deeper intution is this:

(.) is simply defined as

\f g -> \x -> f (g x)

Which we can simplify to

\f g x -> f (g x)

So when you supply it two arguments, it's curried and still needs another argument to resolve. Each time you use (.) with 2 arguments, you create a "need" for one more argument.

(.) . (.) is of course just (.) (.) (.), so let's expand it:

(\f0 g0 x0 -> f0 (g0 x0)) (\f1 g1 x1 -> f1 (g1 x1)) (\f2 g2 x2 -> f2 (g2 x2))

We can beta-reduce on f0 and g0 (but we don't have an x0!):

\x0 -> (\f1 g1 x1 -> f1 (g1 x1)) ((\f2 g2 x2 -> f2 (g2 x2)) x0) 

Substitute the 2nd expression for f1...

\x0 -> \g1 x1 -> ((\f2 g2 x2 -> f2 (g2 x2)) x0) (g1 x1) 

Now it "flips back"! (beta-reduction on f2):
This is the interesting step - x0 is substituted for f2 -- This means that x, which could have been data, is instead a function.
This is what (.) . (.) provides -- the "need" for the extra argument.

\x0 -> \g1 x1 -> (\g2 x2 -> x0 (g2 x2)) (g1 x1) 

This is starting to look normal... Let's beta-reduce a last time (on g2):

\x0 -> \g1 x1 -> (\x2 -> x0 ((g1 x1) x2))

So we're left with simply

\x0 g1 x1 x2 -> x0 ((g1 x1) x2)

, where the arguments are nicely still in order.

Answer 4

So, this is what I get when I do a slightly more incremental expansion

(.) f g   = \x -> f (g x)
(.) . g   = \x -> (.) (g x)
          = \x -> \y -> (.) (g x) y
          = \x -> \y -> \z -> (g x) (y z)
          = \x y z -> (g x) (y z)
(.) . (.) = \x y z -> ((.) x) (y z)
          = \x y z -> \k -> x (y z k)
          = \x y z k -> x (y z k)

Which, according to ghci has the correct type

Prelude> :t (.) . (.)
(.) . (.) :: (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c
Prelude> :t \x y z k -> x (y z k)
\x y z k -> x (y z k)
  :: (t1 -> t) -> (t2 -> t3 -> t1) -> t2 -> t3 -> t
Prelude> 

While I don't know the origins of this combinator, it is likely that it was developed for use in combinatory logic, where you work strictly with combinators, so you can't define things using more convenient lambda expressions. There may be some intuition that goes with figuring these things out, but I haven't found it. Most likely, you would develop some level of intuition if you had to do it enough.

Answer 5

It's easiest to write equations, combinators-style, instead of lambda-expressions: a b c = (\x -> ... body ...) is equivalent to a b c x = ... body ..., and vice versa, provided that x does not appear among {a,b,c}. So,

-- _B = (.)  

_B f g x = f (g x)
_B _B _B f g x y = _B (_B f) g x y
                 = (_B f) (g x) y
                 = _B f (g x) y
                 = f ((g x) y)
                 = f (g x y)

You discover this if, given f (g x y), you want to convert it into a combinatory form (get rid of all the parentheses and variable repetitions). Then you apply patterns corresponding to the combinators' definitions, hopefully tracing this derivation backwards. This is much less mechanical/automatic though.