Hello Julian, Prelude> let f g = g . g Prelude> let sum x y = x + y Prelude> f sum If you are trying to call 'f' and see the result, args are missing. If you are trying to create new type, use 'let'. Prelude> (\x y -> x + y) . (\x y -> x + y) Similar story. Let or args ;)

Prelude> let f g = g . g Prelude> let sum x y = x + y Prelude> let sum' = f sum Occurs check: cannot construct the infinite type: a ~ a -> a If f and sum were defined in a module, given a signature, I suppose this would compile. Similarly, sometimes valid functions defined within function body without signatures sometimes make compiler complain. Once such functions are moved to top (module) level and given a signature, compiler is happy.

On Sun, Jan 3, 2016 at 1:05 PM, Imants Cekusins wrote:

Here is composition signature:

(.) http://hackage.haskell.org/package/base-4.8.1.0/docs/Prelude.html#v:. :: (b -> c) -> (a -> b) -> a -> c

It looks like it is applicable to functions with 1 arg. Sum expects 2 args. I guess this explains why sum can not be passed to f

This isn't accurate, and it's useful to understand why. Every function in Haskell has exactly one argument. Joel touched on this earlier. It's easier to see if you add the implied parentheses to the type signatures: sum :: Num a => a -> (a -> a) f :: (a -> a) -> (a -> a) To really drive it home, let's play with synonyms. type Endo' a = (a -> a) Endo already exists as a newtype in Data.Monoid, thus Endo' here. Now: sum :: Num a => a -> Endo' a f :: Endo' a -> Endo' a

Every function in Haskell has exactly one argument.

well partially applied functions may be used in the intermediary stages of function processing however if programmer expects a function to return primitive value (as opposed to a function), that return value will only be available once that function is fully applied. In other words, for f:: (...) -> z where z is a primitive value (not a function), (...) can be as long as we like, if not full (...) are applied, we get f1::(...')->z To obtain z - the purpose f was written for - we need to pass full (...) although every function may be passed 1 (or even 0) args, n or (in)complete args has some meaning.

On 03.01.2016, at 22:30, Theodore Lief Gannon wrote:

sum :: Num a => a -> (a -> a) f :: (a -> a) -> (a -> a)

To really drive it home, let's play with synonyms.

type Endo' a = (a -> a)

Endo already exists as a newtype in Data.Monoid, thus Endo' here. Now:

sum :: Num a => a -> Endo' a f :: Endo' a -> Endo’ a

ok, this makes sense to me now – thank you very much for your patience. I’m trying to make the conclusion explicit, so please correct me if I’m wrong. if type checking of "f sum" assumes the type variable "a" to be of type Endo' in f, it concludes: sum takes Endo' to Endo' Endo' which looks equivalent to trying to construct an infinite type. The type checker seems not to worry about the more obvious arity/Num restriction of sum, which makes the result more interesting. More generally, if 1) f is a function that maps a function to a function of the same type (a -> a) -> (a -> a) 2) sum is a function that maps a value of type b to a function from (b -> b) 3) then their composition “f sum” would have two constraints: sum maps value a into function b = (a -> a) but f assumes equality between a and b, so that the required type would be one where a = (a -> a). which is possibly inconsistent, e.g. when it is interpreted as a definition of a set which has as its elements all sets of pairs of elements of that same set.

On 03.01.2016, at 22:50, Imants Cekusins wrote: Could you think of a useful practical example of

(a->a->a) . (a->a->a)

Good question. I indeed had nothing else in mind but to reason about functions. Which is quite practical if you are trying to understand haskell! I could imagine useful variants of function application, but that is pure speculation.