60

Ordinary function composition is of the type

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

I figure this should generalize to types like:

(.) :: (c -> d) -> (a -> b -> c) -> a -> b -> d

A concrete example: calculating difference-squared. We could write diffsq a b = (a - b) ^ 2, but it feels like I should be able to compose the (-) and (^2) to write something like diffsq = (^2) . (-).

I can't, of course. One thing I can do is use a tuple instead of two arguments to (-), by transforming it with uncurry, but this isn't the same.

Is it possible to do what I want? If not, what am I misunderstanding that makes me think it should be possible?

Note: This has effectively already been asked here, but the answer (that I suspect must exist) was not given.

Community
  • 1
  • 1
jameshfisher
  • 34,029
  • 31
  • 121
  • 167
  • 4
    The combinator you have is `blackbird :: (c -> d) -> (a -> b -> c) -> a -> -> b -> d`. You can see it as applying a `post-transformer` to regular function application. – stephen tetley Apr 28 '11 at 16:08
  • Great question as it highlights a subtle difference between function composition in math and in Haskell which can be confusing. For this example I prefer the solution of using `uncurry (-)` as it is simpler than the alternatives and points to the underlying issue. – George Co Jul 31 '21 at 13:41

6 Answers6

53

My preferred implementation for this is

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

If only because it is fairly easy to remember.

When instantiating f and f1 to (->) c and (->) d respectively you get the type

(a -> b) -> (c -> d -> a) -> c -> d -> b

which is the type of 

(.) . (.) ::  (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c

but it is a bit easier to rattle off the fmap . fmap version and it generalizes to other functors.

Sometimes this is written fmap fmap fmap, but written as fmap . fmap it can be more readily expanded to allow more arguments.

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

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

etc.

In general fmap composed with itself n times can be used to fmap n levels deep!

And since functions form a Functor, this provides plumbing for n arguments.

For more information, see Conal Elliott's Semantic Editor Combinators.

Edward Kmett
  • 29,632
  • 7
  • 85
  • 107
  • 4
    Moreover, you can mix in other semantic combinators, such as `first` and `second`. For instance: `fmap.first.fmap.second :: (Functor g, Functor f) => (b -> c) -> f (g (d1, b), d) -> f (g (d1, c), d)`. These compositions can be written and read very easily, as they give a path through the type of the overall value being edited to the sub-value actually getting modified. – Conal Apr 28 '11 at 20:57
  • 1
    IIRC, thereis the combinator `.:` defined as `.: = (.).(.)`. – fuz Apr 29 '11 at 08:10
  • Very true. I do find the *n*-times composed `fmap` or `result` combinators to be more inituitive and useful as the `.:` approach doesn't generalize without a linear number of implementations. – Edward Kmett Apr 29 '11 at 14:48
  • 7
    This answer is enlightening. I did not know that `(.)` is nothing but `fmap` specialized for the functor `(->) c`. – Tsuyoshi Ito May 26 '11 at 03:12
42

The misunderstanding is that you think of a function of type a -> b -> c as a function of two arguments with return type c, whereas it is in fact a function of one argument with return type b -> c because the function type associates to the right (i.e. it's the same as a -> (b -> c). This makes it impossible to use the standard function composition operator.

To see why, try applying the (.) operator which is of type (y -> z) -> (x -> y) -> (x -> z) operator to two functions, g :: c -> d and f :: a -> (b -> c). This means that we must unify y with c and also with b -> c. This doesn't make much sense. How can y be both c and a function returning c? That would have to be an infinite type. So this does not work.

Just because we can't use the standard composition operator, it doesn't stop us from defining our own.

 compose2 :: (c -> d) -> (a -> b -> c) -> a -> b -> d
 compose2 g f x y = g (f x y)

 diffsq = (^2) `compose2` (-)

Usually it is better to avoid using point-free style in this case and just go with

 diffsq a b = (a-b)^2
hammar
  • 138,522
  • 17
  • 304
  • 385
  • 6
    You can get "halfway there" without defining your own composition: `sumSq a = (^2) . (+a)`. By naming and applying the first argument we've constructed a function of type `b -> c` for use with regular composition. – Thomas M. DuBuisson Apr 28 '11 at 15:52
  • 3
    Indeed you can, but it quickly gets messy and it "feels wrong" in this case because it treats the two arguments differently while the function is commutative. – hammar Apr 28 '11 at 16:02
  • Nice explanation, thanks. For some reason, writing `compose2` was bending my brain. I *will* learn. – jameshfisher Apr 28 '11 at 16:22
  • `compose2 = g f x y = g (f x y)`: the first equal sign has to be removed. – Tsuyoshi Ito May 26 '11 at 03:07
  • 7
    I like the point-free style `(g .) . f`, but I admit it looks a bit confusing with sections `((^2) .) . (-)` – Max Apr 28 '15 at 15:26
  • "...it would have to be an infinite type". NOTE: It is not just a word --- there is an error of trying to construct an infinite type in Haskell. I think it appears if you can expand the type variable infinitely many times like this : `x = [x] ` therefore `x = [[x]] = [[[x]]]` and etc. It reminds me of the [axiom of regularity](https://en.wikipedia.org/wiki/Axiom_of_regularity) BTW. – LRDPRDX Oct 04 '21 at 21:07
24

I don't know of a standard library function that does this, but the point-free pattern that accomplishes it is to compose the composition function:

(.) . (.) :: (b -> c) -> (a -> a1 -> b) -> a -> a1 -> c
mightybyte
  • 7,282
  • 3
  • 23
  • 39
  • 6
    While this is a cute trick, I would not recommend writing that kind of code. – hammar Apr 28 '11 at 16:09
  • 1
    I'd like to `let (f .. g) a b = f (g a b)`, but `..` is syntax for something else. And `...` wouldn't look right. – dave4420 Apr 28 '11 at 16:17
  • 2
    @hammar True. I wouldn't either. But it does give a different insight into how `(.)` interacts with functions only having a single argument. – mightybyte Apr 28 '11 at 16:18
  • 3
    Compose compose with compose. Interesting. – Dan Burton Apr 28 '11 at 17:09
  • i love it. more than just a cute trick i think its very informative. while i see how this might not belong in 'end' code, its a great educational exercise and i think ive gained some insight from it. – jon_darkstar Apr 30 '11 at 17:27
8

As Max pointed out in a comment:

diffsq = ((^ 2) .) . (-)

You can think of f . g as applying one argument to g, then passing the result to f. (f .) . g applies two arguments to g, then passes the result to f. ((f .) .) . g applies three arguments to g, and so on.

\f g -> (f .) . g :: (c -> d) -> (a -> b -> c) -> a -> b -> d

If we left-section the composition operator with some function f :: c -> d (partial application with f on the left), we get:

(f .) :: (b -> c) -> b -> d

So we have this new function which expects a function from b -> c, but our g is a -> b -> c, or equivalently, a -> (b -> c). We need to apply an a before we can get what we need. Well, let's iterate once more:

((f .) .) :: (a -> b -> c) -> a -> b -> d
Community
  • 1
  • 1
gdejohn
  • 7,451
  • 1
  • 33
  • 49
8

I was going to write this in a comment, but it's a little long, and it draws from both mightybyte and hammar.

I suggest we standardize around operators such as .* for compose2 and .** for compose3. Using mightybyte's definition:

(.*) :: (c -> d) -> (a -> b -> c) -> (a -> b -> d)
(.*) = (.) . (.)

(.**) :: (d -> e) -> (a -> b -> c -> d) -> (a -> b -> c -> e)
(.**) = (.) . (.*)

diffsq :: (Num a) => a -> a -> a
diffsq = (^2) .* (-)

modminus :: (Integral a) => a -> a -> a -> a
modminus n = (`mod` n) .* (-)

diffsqmod :: (Integral a) => a -> a -> a -> a
diffsqmod = (^2) .** modminus

Yes, modminus and diffsqmod are very random and worthless functions, but they were quick and show the point. Notice how eerily easy it is to define the next level by composing in another compose function (similar to the chaining fmaps mentioned by Edward).

(.***) = (.) . (.**)

On a practical note, from compose12 upwards it is shorter to write the function name rather than the operator

f .*********** g
f `compose12` g

Though counting asterisks is tiring so we may want to stop the convention at 4 or 5 .

[edit] Another random idea, we could use .: for compose2, .:. for compose3, .:: for compose4, .::. for compose5, .::: for compose6, letting the number of dots (after the initial one) visually mark how many arguments to drill down. I think I like the stars better though.

Dan Burton
  • 53,238
  • 27
  • 117
  • 198
  • I thought about this whilst mucking about with Data.Aviary. My conclusion was that giving composition operators ASCII names was a waste of name-space, ASCII names should be "reserved" for extra mathematical operators (like Conal Elliott's vector-space). Type-setting mathematically inclined code with with textual names in backticks is horrible, so math operators should get first pick of the name-space. If you can't think up a good textual name for a composition operator, you're probably better of with pointful code. – stephen tetley Apr 28 '11 at 19:11
  • @stephen [Function composition](http://en.wikipedia.org/wiki/Function_composition) is a mathematical operation, although I admit it gets fuzzy when functions have multiple arguments. I can't really imagine how `.*` would be used as a math operator, though, and composition functions like this are almost *always* invoked in infix style. – Dan Burton Apr 28 '11 at 22:13
  • 1
    If compose2 is `.:` and compose3 is `.:.` then compose must be `..`, but it isn't! Unthinkable unfairness! – Rotsor May 04 '11 at 07:11
3

Here's what I think is an elegant way to achieve what you want. The Functor type class gives a way to 'push' a function down into a container so you can apply it to each element using fmap. You can think of a function a -> b as a container of bs with each element indexed by an element of a. So it's natural to make this instance:

instance Functor ((->) a) where
  fmap f g = f . g

(I think you can get that by importing a suitable library but I can't remember which.)

Now the usual composition of f with g is trivially an fmap:

o1 :: (c -> d) -> (b -> c) -> (b -> d)
f `o1` g = fmap f g

A function of type a -> b -> c is a container of containers of elements of type c. So we just need to push our function f down twice. Here you go:

o2 :: (c -> d) -> (a -> (b -> c)) -> a -> (b -> d)
f `o2` g = fmap (fmap f) g

In practice you might find you don't need o1 or o2, just fmap. And if you can find the library whose location I've forgotten, you may find you can just use fmap without writ ing any additional code.

sigfpe
  • 7,996
  • 2
  • 27
  • 48
  • i.e., `o2 = fmap . fmap`, or `o2 = result . result` where `result` is defined in a differently-general form in the `DeepArrow` on Hackage. – Conal Apr 28 '11 at 21:00
  • @Conal Yes, but I was trying to make the code as perspicuous as possible. – sigfpe Apr 28 '11 at 21:38
  • 1
    user207442: In that case, you might particularly enjoy semantic editor combinators such as the ones I suggested above. They clarify the general case rather than piling on ad hoc specializations, and they're quite clear & illuminating once one groks what's going on. On the other hand, for just a special case, your `o2` is simpler. – Conal Aug 15 '11 at 20:48
  • [Semantic editor combinators](http://conal.net/blog/posts/semantic-editor-combinators), a very illuminating article indeed as usual from Conal Elliott. – AndrewC May 14 '14 at 21:07