11

In ghci,

:t ((+).(+))
> ((+).(+)) :: (Num (a -> a), Num a) => a -> (a -> a) -> a -> a

but what is this thing? Can any one give me an example of the use of this please?

How can one composite 2 functions that take 2 parameters each? for example, how does (map.map) :: (a -> b) -> [[a]] -> [[b]] work?

(^.^) (-.-) (+.+) (can't help making funny faces out of it. PS: I thought it means to tell the compiler how you feel today)

neontapir
  • 4,698
  • 3
  • 37
  • 52
Larry
  • 858
  • 10
  • 16
  • `((+).(+))` does not work, but `((+) . uncurry (+))` does! Not really a face anymore, though... – Swiss May 23 '14 at 09:52
  • 1
    I see. To understand this question, it would be easier if I knew `(+):: (Num a) => a -> a -> a` is actually right associated as `(+):: (Num a) => a -> (a -> a)`, so it's like a function that takes in a Num, and gives back a function `(a -> a)`, still with one parameter then, that's why it can be composed. The same applies to `map :: (a -> b) -> a -> [b] -> a` is actually `map :: (a -> b) -> (a -> [b] -> a)` – Larry May 24 '14 at 00:58

4 Answers4

12

Num (a -> a) (or e.g. Eq (a -> a)) is basically an indicator for code that doesn't make any sense1, but the compiler nevertheless deduces a (nonsensical) type signature. Usually it turns up when you've forgotten to apply a function to some argument. In this case, obviously (+) needs a "plain number" argument to become a "simple function" to which you can post-compose another such function.

However, (a -> a) is sure enough a valid type of functions that you can also pass on, just not as numbers. For instance, map . (+) is a perfectly good combination:

Prelude> :t map . (+)
map . (+) :: Num b => b -> [b] -> [b]
Prelude> zipWith (map . (+)) [10,20,30] [[1,2],[3,4]]
[[11,12],[23,24]]

because map actually expects a function as its first argument. Similarly,

Prelude> zipWith (map . map) [(+10),(+20),(+30)] [[[1,2],[3,4]],[[5,6]]]
[[[11,12],[13,14]],[[25,26]]]

Here, the right map takes a simple function (like numerical increment) and returns the corresponding list-map function. That function is then fed to the left map resulting in a function that maps nested lists.

1Actually, you can force it to make sense by defining

instance (Num a) => Num (b -> a) where
  fromInteger x = const $ fromInteger x
  f + g = \x -> f x + g x

Personally, I'm not a fan of this. It confusing, for instance let a = 3 in 4 a produces 4 when most people would expect multiplication to 12.

leftaroundabout
  • 117,950
  • 5
  • 174
  • 319
  • Number literals as constant functions is easily misleading, but I do wish pointwise summation were a thing. – J. Abrahamson May 23 '14 at 13:37
  • @J.Abrahamson right, that's one of the things that can excellently be done with `vector-space` (i.e. [`^+^`](http://hackage.haskell.org/package/vector-space-0.8.6/docs/Data-AdditiveGroup.html)). – leftaroundabout May 23 '14 at 23:26
3

That won't work. As ghci tells you, you should have an instance of Num (a -> a) in order to use that function, but a -> a obviously isn't a number.

This is because (+) assumes to get two numerical parameters, but with the composition you wrote you gave it a partially applied function instead, the a -> a mentioned in the computed type signature.

Usually, when composing functions which take more than one parameter, you partially apply them first in order to reduce them to functions which take just one parameter, e.g. (+1) . (*2) applied to 3 will result in (3 * 2) + 1 = 7

Riccardo T.
  • 8,907
  • 5
  • 38
  • 78
  • yeah, I think the compiler should throw an error since (a -> a) is definitely not in the `Num` typeclass. But does `map.map` work and why? : >.... – Larry May 23 '14 at 09:29
  • 3
    @Larry: it definitely _should_ not be in the `Num` type class, but people might be idiots and put it in there. It's not the compilers task to prevent stuff that could possibly made sense. – leftaroundabout May 23 '14 at 09:45
2

f . f can make sense for a binary function f; it entirely depends on the signature of f. The key is that partial application of the inner f to its first argument has to give something that is a valid input to the outer f.

For example, with map :: (a -> b) -> [a] -> [b], we can hand-unify map . map:

map :: (a -> b) -> [a] -> [b]
map :: (c -> d) -> [c] -> [d]
. :: (e -> f) -> (f -> g) -> (e -> g)

e === a -> b
f === [a] -> [b]
  === c -> d
c === [a]
d === [b]
g === [c] -> [d] === [[a]] -> [[b]]

map . map :: e -> g
    :: (a -> b) -> [[a]] -> [[b]]

So, as expected, map . map takes a transformation a -> b and gives us a transformation from list-of-list-of-a to list-of-list-of-b. We can check this by hand-applying (map . map) f ll:

(map . map) f ll
    = map (map f) ll
    = map (\l -> map f l) ll

But if we try the same with (+) :: Num a => a -> a -> a, it all goes horribly wrong:

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

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

(+) . (+) :: c -> e
    :: (Num a, Num (a -> a)) => a -> (a -> a) -> (a -> a)

So, partial application of the inner + is giving a transformation a -> a, the outer + is then trying to add that transformation to another function which we are expected to supply. Since it doesn't make sense to add transformations, the overall (+) . (+) doesn't make sense either.

ecatmur
  • 152,476
  • 27
  • 293
  • 366
1

g . f means applying f first, then applying g to the result of f, in other words, it can be rewritten as

\x -> g (f x)

Therefore,

((+) . (+))

can be rewritten as

\x -> (\y -> (x +) + y)

According to the type of (+), in the above lambda abstraction, x needs having type Num a => a, y having type Num a => Num (a -> a), as inferred by ghci

(Num a, Num (a -> a)) => a -> (a -> a) -> a -> a

So if we have made a -> a an instance of type class Num a, for example, here is one way to achieve that

    {-# LANGUAGE FlexibleInstances #-}

    instance (Num a) => Num ((->) a a) where
        a + b = \x -> a x + b x
        a * b = \x -> a x * b x
        a - b = \x -> a x - b x
        negate a = \x -> negate $ a x
        abs a = \x -> abs $ a x
        signum a = \x -> signum $ a x
        fromInteger n = \_x -> fromInteger n

we can use ((+) . (+)) like this

    *Main> ((+) . (+)) 1 (+2) 3
    9

Because ((+) . (+)) equals

\x -> \y -> (x +) + y

which means ((+) . (+)) 1 (+2) 3 equals

((1 + ) + (+ 2)) 3

according to the definition of (+) in the instance of (a -> a), ((1+) + (+2)) equals

\x -> (1+x) + (x+2)

So ((1+) + (+2)) 3 equals (1+3) + (3+2), which is 9, as given by ghci.

map . map is similar, as indicated by its type, given by ghci:

    (a -> b) -> [[a]] -> [[b]]

the first argument of that function should be a function of type a->b, the second argument should be a nested list of type [[a]], and that composed function map . map will apply the first argument to each element of each list in its second argument, return a nested list of type [[b]]. For example

    *Main> (map . map) (+1) [[1,2], [3,4,5]]
    [[2,3],[4,5,6]]
Lee Duhem
  • 14,695
  • 3
  • 29
  • 47