function composition type inference in haskell - haskell

In haskell, the type of (.) function is:
(.) :: (b -> c) -> (a -> b) -> a -> c
And the type of (.) (.) is:
(.) (.) :: (a -> b -> c) -> a -> (a1 -> b) -> a1 -> c
I am not able to deduce the result, how is this done?

(.) :: (b -> c) -> (a -> b) -> a -> c
Let's go through it. First thing this function takes is (b -> c) (so a function from b to c), cool. By adding a pair of (redundant) parentheses:
(.) :: (b -> c) -> ((a -> b) -> a -> c)
^-- I am b' ^-- I am c' -- (b' and c' not to have name clash)
That first part, we gave to the function (i.e. has been taken care of):
(.) (.) :: (a -> b') -> a -> c'
-- after substituting stuff (b' and c')
(.) (.) :: (a -> (b -> c)) -> a -> ((a1 -> b) -> a1 -> c)
^-- of course a1 /= a
-- you could eliminate redundant parentheses
(.) (.) :: (a -> b -> c) -> a -> (a1 -> b) -> a1 -> c
-- wee
I hope this settles it. Main point is: type inference is easy to 'get' and once you get it is only a matter of substitution to reach what ghci automagically infers.
ot: we could call this quizzical operator boobs.

Related

Calculating the type of `map . foldr`

map :: (a -> b) -> [a] -> [b]
foldr :: Foldable t => (a -> b -> b) -> b -> t a -> b
What is a systematic way to figure out the type for map . foldr ? I know how to do it for map foldr but get confused when it comes to a composition.
Thanks!
Obviously there must be a systematic way, otherwise the Haskell compiler could not do type inference.
One way we can do this ourselves is insert the types step by step:
We have the following types:
(.) :: (b -> c) -> (a -> b) -> (a -> c)
map :: (a' -> b') -> [a'] -> [b']
foldr :: Foldable t => (a'' -> b'' -> b'') -> b'' -> t a'' -> b''
Note that you have to choose different names for types appearing in different signatures for this to work out.
1. supply map to (.)
If we supply a generic function f to (.) we get the following types:
(.) :: (b -> c) -> (a -> b) -> (a -> c)
(.) f :: (a -> b) -> (a -> c)
f :: (b -> c)
choose f to be map:
map :: (a' -> b') -> [a'] -> [b']
equal to
map :: (a' -> b') -> ([a'] -> [b'])
as f has type (b -> c) we can conclude:
b :: (a' -> b')
c :: ([a'] -> [b'])
insert our inferred types:
(.) f :: (a -> b) -> (a -> c)
(.) map :: (a -> (a' -> b')) -> (a -> ([a'] -> [b']))
we can drop some parentheses:
(.) map :: (a -> (a' -> b')) -> a -> ([a'] -> [b'])
(.) map :: (a -> (a' -> b')) -> a -> [a'] -> [b']
(.) map :: (a -> a' -> b') -> a -> [a'] -> [b']
2. supply foldr to (.) map
Again start by suppling a generic function g:
(.) map :: (a -> a' -> b') -> a -> [a'] -> [b']
(.) map g :: a -> [a'] -> [b']
g :: (a -> a' -> b')
choose g to be foldr:
foldr :: Foldable t => (a'' -> b'' -> b'') -> b'' -> t a'' -> b''
equal to
foldr :: Foldable t => (a'' -> b'' -> b'') -> b'' -> (t a'' -> b'')
as g has type (a -> a' -> b') we can conclude:
a :: (a'' -> b'' -> b'')
a' :: b''
b' :: Foldable t => t a'' -> b''
insert our inferred types:
(.) map foldr :: a -> [a'] -> [b']
(.) map foldr :: Foldable t => (a'' -> b'' -> b'') -> [b''] -> [t a'' -> b'']
Which is the same type we get, when asking ghci for the type:
> :t ((.) map foldr)
((.) map foldr) :: Foldable t => (a1 -> a2 -> a2) -> [a2] -> [t a1 -> a2]
map . foldr is actually (.) map foldr. Adding the type of (.) into the mix we get
foldr :: Foldable t => (a -> (r->r)) -> (r -> (t a -> r))
map :: (i -> j) -> ([i] -> [j])
(.) :: ( b -> c ) -> ( d -> b ) -> (d -> c)
-----------------------------------------------------------------------------------------
-- 4 2 1 3
-----------------------------------------------------------------------------------------
(.) map foldr :: Foldable t => (d -> c)
where d ~ a -> (r -> r) -- 1
c ~ [i] -> [j] -- 2
b ~ r -> (t a -> r) -- 3
~ i -> j -- 4
-------------------
i ~ r -- 5
j ~ t a -> r -- 6
thus
map . foldr :: Foldable t => a -> (r -> r) -> [i] -> [j] -- by 1,2
~ Foldable t => a -> (r -> r) -> [r] -> [t a -> r] -- by 5,6
Here we used the application type derivation rule,
f :: A -> B
x :: A
---------------
f x :: B
(otherwise known as modus ponens, in logic).
We could also use a composition type derivation rule which is the application rule specialized for (.), or equivalently (>>>) = flip (.):
g :: B -> C
f :: A -> B
------------------------
f >>> g :: A -> C
g . f :: A -> C
To fit this pattern, we write the types down a bit differently, and obtain the result immediately:
map :: (i -> j ) -> ([i] -> [ j ])
foldr :: Foldable t => (a -> (r->r)) -> (r -> (t a -> r))
------------------------------------------------------------------------------------
foldr >>> map :: Foldable t => (a -> (r->r)) -> [r] -> [t a -> r]
map . foldr :: Foldable t => (a -> (r->r)) -> [r] -> [t a -> r]
It is much more intuitive this way.
Ok, rather than using an automatic method to infer the type I thought maybe you’ll be interested in a more intuitive answer:
As I’m sure you know, map . foldr is equivalent to (\x -> map (foldr x)). Let’s start with that.
What should be the type of x ? Well, since it’s the first parameter to foldr, it should look like a function that takes some value, some accumulator, and return something of the same type as the accumulator (by definition of foldr). Thus :
x :: (a -> b -> b)
Now that we have the type of the first parameter, let’s look at the rest.
Once (foldr x) is applied, we get back a function that stills waits for an initial accumulator value, and then for any foldable type, and returns a value of the same type as the accumulator (for example, the sum of every element in a list).
So the type of (foldr x) should be
Foldable t => b -> t a -> b
Ok but we're not done, let’s see what happens with the use of map now.
map should first be given a function (by definition). The return value of (foldr x) is seen as that, which means that this use of map considers that (b -> t a -> b) is the type of the function that needs to be applied to every element of a list.
Maybe it’s clearer written as (b -> (t a -> b)). So, this use of map considers that it is given a function that takes some input of type b and returns a function that itself takes a foldable a and returns a b.
Ok we’re almost there. Now, map still needs another argument: a list which elements are of the same type as the input of the function it will apply. So since the function we want to apply (the result of (foldr x)) takes a b, our use of map will take a [b].
So now we have :
(a -> b -> b) -> [b] -> …
We’re just lacking the type of the output value of that function composition, which is the type of the output value of this specific use of map. Since the function that is applied with map returns something of type (t a -> b), then the list of thing we will obviously return will be of type [t a -> b].
So in the end you have
Foldable t => (a -> b -> b) -> [b] -> [t a -> b]
as the type of map . foldr.

The type of foldr (.) id

I'm trying to figure out the type of the expression :
foldr (.) id
GHCI gives me :
foldr (.) id :: Foldable t => t (b -> b) -> b -> b
And I can't figure this out. foldr type is Foldable t => (a -> b -> b) -> b -> t a -> b.
So it takes 3 parameters as input. So i thought that foldr (.) id should take a single parameter as input. Can someone explain how to analyze the type of this expresion ?
The type Foldable t => t (b -> b) -> b -> b reads as:
(Foldable t => ...) Choose any list-like "container" type t,
(t (b -> b) -> ... ) then provide as an argument a t-container of functions b -> b,
(b -> b) the final result will be a function b -> b.
So, it's only slightly more general than: "give me a list of functions, and I will produce a function".
Indeed, when we use lists as containers:
foldr (.) id [f1,f2,f3,...,fn]
results, by definition of foldr, in
f1 . (f2 . (f3 . ... (fn . id) ...))
which is the composition of all the functions in the list.
So i thought that foldr (.) id should take a single parameter as input.
It does: the argument has type t (b -> b). Every function in Haskell takes a single parameter as input. E.g.
foo :: T -> U -> W -> Z
takes T and returns a function U -> W -> Z.
Now, we can also say that foo takes two arguments of type T and U and returns a function W -> Z. Or That it takes three arguments T, U, and W, and returns a Z. There is no real difference between these interpretations of a type, thanks to currying, so we can pick the one which is the easiest to grasp.
In your case, the result type of foldr (.) id is b -> b, so one usually interprets the first b as an additional argument. This does not provide a good intuition, though. It's easier to think of b -> b being the result type.
More technically: the type of foldr is (renaming variables for clarity).
foldr :: Foldable t => (a -> c -> c) -> c -> t a -> c
In foldr (.) id, we can see that the type of the second argument is id :: b -> b, hence we are using c = (b -> b), as if we specialized the above type to:
foldr :: Foldable t => (a -> (b -> b) -> (b -> b)) -> (b -> b) -> t a -> (b -> b)
Now, the first argument must have type (.) :: (a -> (b -> b) -> (b -> b)) to type check. This is possible only if a = (b -> b). Hence, we specialize again.
foldr :: Foldable t =>
((b -> b) -> (b -> b) -> (b -> b)) ->
(b -> b) ->
t (b -> b) ->
(b -> b)
which is the final type: after this specialization, foldr can then be applied to (.) and id.
All the specializations above are inferred automatically by GHC from your code. Essentially, GHC chooses a and c in the only way that can make your code type check
TLDR answer:
foldr (.) id :: Foldable t => t (b -> b) -> b -> b
DOES take one argument. It takes a t (b -> b) and returns a b -> b.
This confusion is usually due to Haskell allowing the omission of parens in type signatures. Parens in types associate to the right. So another way to look at this:
foldr :: Foldable t => (a -> r -> r) -> (r -> (t a -> r))
(.) :: (c -> d) -> (b -> c) -> (b -> d)
-- a -> r -> r
(.) :: (c -> c) -> (b -> c) -> (b -> c)
foldr (.) :: Foldable t => (b -> c) -> (t (c -> c) -> (b -> c))
id :: b -> b
foldr (.) id :: Foldable t => t (b -> b) -> (b -> b)
You could
resultFun = foldr (.) id [(+1), (*4)]
resultFun 5
>>> 21
Or even
foldr (.) id [(+1), (*4)] 5
>>> 21

Why does (.) map have this type?

I tried to find the type of the function (.) map but somehow find that it is ((a -> d) -> (a -> e)) -> ([d] -> [e]) which according to GHCI is not correct because it should be (.) map :: (a1 -> a2 -> b) -> a1 -> [a2] -> [b].
What am I doing wrong?
Deriving the type...
We have as ingredients:
(.) :: (b -> c) -> (a -> b) -> a -> c
map :: (d -> e) -> [d] -> [e]
(here I used different type identifiers for the two functions to avoid any confusion). A more verbose form (where we make it more explicit that every function takes exactly one parameter) is:
(.) :: (b -> c) -> ((a -> b) -> (a -> c))
map :: (d -> e) -> ([d] -> [e])
Since map is the first parameter of (.) that means that its type (d -> e) -> ([d] -> [e]) should match the input type of the (.) function (so b -> c). This thus means:
b -> c
~ (d -> e) -> ([d] -> [e])
------------------------------
b ~ (d -> e), c ~ ([d] -> [e])
So that means that the result type of (.) map is:
(a -> b) -> (a -> c)
which is equivalent to:
(a -> (d -> e)) -> (a -> ([d] -> [e]))
or less verbose:
(.) map :: (a -> d -> e) -> a -> [d] -> [e]
... and its implementation
The (.) function can be seen as (.) f g == \x -> f (g x). So that means that our function
h = (.) map
is equivalent to:
h f x = map (f x)
It thus takes as input a function f and an object x, and than performs a map with f x as function.
Semancially you could say that we make a "map where one has to inject a 'contect'-objecct" of type a. This context is then taken into account by the processor. This could be useful if we want to apply multiple maps, each with a small change, and thus first pass a "context-object". This is of course an interpretation of humans. For a compiler, the x can have any use, interpretation, etc.
You have probably tried to match the functions by looking at the definition
Types of the two functions
(.) :: ((b -> c) -> (a -> b) -> a -> c)
map :: (d -> e) -> [d] -> [e]
and then trying to match d to b and e to c. Which gives you ((a -> d) -> (a -> e)) -> ([d] -> [e]), now you could match [d] to a and [e] to d. This is however not correct because according to the type definition of map, e and d could be of different type, i.e. d could be of type [e] but it doesn't have to.
The correct way to find the type of this function is to look at the definition of the types
Types of the two functions
(.) :: ((b -> c) -> (a -> b) -> a -> c)
map :: (d -> e) -> [d] -> [e]
and then to match (d -> e) to b and [d] -> [e] to c which gives you (a -> (d -> e)) -> a -> ([d] -> [e]), by removing the superfluous brackets and renaming the type variables you get (a -> b -> c) -> a -> [b] -> [c]. This is the same result GHCI gives you.
When I don't understand the type of a function, I write types using different letters:
(.) :: (b -> c) -> (a -> b) -> a -> c
map :: (x -> y) -> [x] -> [y]
now we are providing map as the first argument of (.) so we can deduce:
b -> c == (x -> y) -> [x] -> [y] -- by matching first arguments we get...
b == x -> y
c == [x] -> [y]
since we have already provided the first argument of (.), the whole b -> c part disappears.
(.) map :: (a -> b) -> a -> c -- Using the above equations for b and c
(.) map :: (a -> x -> y) -> a -> [x] -> [y] -- changing variables names
(.) map :: (a1 -> a2 -> b) -> a1 -> [a2] -> [b]
as GHCi plots

Bird name for the (=<<) combinator?

The Haskell aviary combinators lists (=<<) as:
(a -> r -> b) -> (r -> a) -> r -> b
Is there an official bird-name for this? Or can it be derived via the pre-existing ones?
Is there an official bird-name for this?
I can't find it in Data.Aviary.Birds, so I suppose there's not. If there was, it probably would've been referenced in the list you linked.
Or can it be derived via the pre-existing ones?
Surely. The easiest might be to start with the starling whose signature is similar, and just compose it with flip, i.e.
(=<<) = bluebird starling cardinal
maybe will be correctly like: blackbird warbler bluebird
this is like
(...) = (.) . (.) -- blackbird
(.) -- bluebird
join -- warbler
-- and your function will be
f = join ... (.)
Quoting a comment:
Btw do you have any advice on how to combine combinators to get a specific signature? I feel like I'm missing some trick (my current technique of staring at a list and doing mental gymnastics doesn't scale too well!)
Let the types guide you. You are looking for:
-- This name is totally made-up.
mino :: (b -> a -> c) -> (a -> b) -> a -> c
While you won't find it in the list, there is something quite similar:
starling :: (a -> b -> c) -> (a -> b) -> a -> c
If only we had a way to somehow twist starling into what we want...
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino = f starling
-- f :: ((a -> b -> c) -> (a -> b) -> a -> c) -> (b -> a -> c) -> (a -> b) -> a -> c
This mysterious f has a rather unwieldy type, so let's abbreviate it for a moment: with x ~ b -> a -> c, y ~ a -> b -> c and z -> (a -> b) -> a -> c, we have
f :: (y -> z) -> x -> z
Another look at the list shows this fits the result type of queer:
queer :: (a -> b) -> (b -> c) -> a -> c
Progress!
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino = queer g starling
-- g :: x -> y
-- g :: (b -> a -> c) -> a -> b -> c
As for g, there is a great candidate near the top of the list:
cardinal :: (a -> b -> c) -> b -> a -> c
And there it is:
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino = queer cardinal starling
queer, of course, is cardinal bluebird (i.e. reverse function composition), which leads us back to Bergi's bluebird starling cardinal.
GHC can actually assist you with this kind of derivation:
import Data.Aviary.Birds
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino = _f starling
GHCi> :l Mino.hs
[1 of 1] Compiling Main ( Mino.hs, interpreted )
Mino.hs:4:8: error:
* Found hole:
_f
:: ((a0 -> b0 -> c0) -> (a0 -> b0) -> a0 -> c0)
-> (b -> a -> c) -> (a -> b) -> a -> c
Where: `b0' is an ambiguous type variable
`a0' is an ambiguous type variable
`c0' is an ambiguous type variable
`b' is a rigid type variable bound by
the type signature for:
mino :: forall b a c. (b -> a -> c) -> (a -> b) -> a -> c
at Mino.hs:3:1-43
`a' is a rigid type variable bound by
the type signature for:
mino :: forall b a c. (b -> a -> c) -> (a -> b) -> a -> c
at Mino.hs:3:1-43
`c' is a rigid type variable bound by
the type signature for:
mino :: forall b a c. (b -> a -> c) -> (a -> b) -> a -> c
at Mino.hs:3:1-43
Or perhaps `_f' is mis-spelled, or not in scope
* In the expression: _f
In the expression: _f starling
In an equation for `mino': mino = _f starling
* Relevant bindings include
mino :: (b -> a -> c) -> (a -> b) -> a -> c (bound at Mino.hs:4:1)
|
4 | mino = _f starling
| ^^
Failed, no modules loaded.
If you want a clean output, though, you have to ask gently:
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE PartialTypeSignatures #-}
import Data.Aviary.Birds
mino :: forall b a c. (b -> a -> c) -> (a -> b) -> a -> c
mino =
let s :: (a -> b -> c) -> _
s = starling
in _f s
(A type annotation to starling would make defining s unnecessary; that style, however, would get ugly very quickly with more complicated expressions.)
GHCi> :l Mino.hs
[1 of 1] Compiling Main ( Mino.hs, interpreted )
Mino.hs:10:8: error:
* Found hole:
_f
:: ((a -> b -> c) -> (a -> b) -> a -> c)
-> (b -> a -> c) -> (a -> b) -> a -> c
Where: `b' is a rigid type variable bound by
the type signature for:
mino :: forall b a c. (b -> a -> c) -> (a -> b) -> a -> c
at Mino.hs:6:1-57
`a' is a rigid type variable bound by
the type signature for:
mino :: forall b a c. (b -> a -> c) -> (a -> b) -> a -> c
at Mino.hs:6:1-57
`c' is a rigid type variable bound by
the type signature for:
mino :: forall b a c. (b -> a -> c) -> (a -> b) -> a -> c
at Mino.hs:6:1-57
Or perhaps `_f' is mis-spelled, or not in scope
* In the expression: _f
In the expression: _f s
In the expression:
let
s :: (a -> b -> c) -> _
s = starling
in _f s
* Relevant bindings include
s :: (a -> b -> c) -> (a -> b) -> a -> c (bound at Mino.hs:9:9)
mino :: (b -> a -> c) -> (a -> b) -> a -> c (bound at Mino.hs:7:1)
|
10 | in _f s
| ^^
Failed, no modules loaded.
The process described above still involves quite a bit of staring at the list, as we are working it out using nothing but the birds in their pointfree majesty. Without such constraints, though, we would likely proceed in a different manner:
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino g f = _
The hole has type a -> c, so we know it is a function that takes an a:
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino g f = \x -> _
-- x :: a
The only other thing that takes an a here is g:
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino g f = \x -> g _ x
The type of the hole is now b, and the only thing that gives out a b is f:
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino g f = \x -> g (f x) x
This, of course, is the usual definition of the reader (=<<). If we flip g, though...
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino g f = \x -> flip g x (f x)
... the reader (<*>) (i.e. the S combinator) becomes recogniseable:
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino g f = \x -> (<*>) (flip g) f x
We can then write it pointfree...
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino = (<*>) . flip
... and translate to birdspeak:
mino :: (b -> a -> c) -> (a -> b) -> a -> c
mino = bluebird starling cardinal

Can't figure out why (flip .) has this type [duplicate]

This question already has an answer here:
Which is the type of (flip .)?
(1 answer)
Closed 8 years ago.
Consider:
:type (flip .)
(flip .) :: (a -> a1 -> b -> c) -> a -> b -> a1 -> c
I just can't figure out why. As I understand, flip has the following type:
flip :: (a -> b -> c) -> b -> a -> c
In addition (.) has the following type:
(.) :: (b1 -> c1) -> (a1 -> b1) -> a1 -> c1
Hence, unifying the types I get:
a = (b1 -> c1) -> (a1 -> b1)
b = a1
Which gives:
(flip .) :: a1 -> ((b1 -> c1) -> (a1 -> b1)) -> c1
Which is far from the actual type.
What am I doing wrong? Any sort of help would be appreciated.
Consider the type of flip and function composition:
flip :: (a -> b -> c) -> b -> a -> c
(.) :: (b -> c) -> (a -> b) -> a -> c
Now you can either apply (.) to flip or else apply flip to (.).
In the first case:
(flip .)
-- is the same as
(.) flip
-- i.e. you are applying (.) to flip
Hence you get:
flip :: (a -> b -> c) -> b -> a -> c
|___________| |___________|
| |
(.) :: b c -> (a -> b) -> a -> c
-- Hence:
(flip .) :: (a -> a1 -> b -> c) -> a -> b -> a1 -> c
(.) flip :: (a -> a1 -> b -> c) -> a -> b -> a1 -> c
In the second case:
(flip (.))
-- is the same as
flip (.)
-- i.e. you are applying flip to (.)
Hence you get:
(.) :: (b -> c) -> (a -> b) -> a -> c
|______| |______| |______|
| | |
flip :: a b c -> b -> a -> c
-- Hence:
(flip (.)) :: (a -> b) -> (b -> c) -> a -> c
flip (.) :: (a -> b) -> (b -> c) -> a -> c
The problem is that when you write (flip .) Haskell assumes that it is a section. Hence it considers flip as an argument since . is an operator. To treat an operator as a function you need to parenthesize it. Hence (flip (.)) is treated as applying flip to (.). In this case the extra set of parentheses are not required. You can simply write it as flip (.).

Resources