I got the following question at a test:

Write a function f with the following type a -> b -> (a -> b). a and b should not be bound in any sense, the shorter the code, the better.

I came up with f a b = \x -> snd ([a,x],b). Can you find something tinier?

Currently the winner is: f _=(.f).const

  • 1
    \$\begingroup\$ @hammar: or f _ b _ = b, but, given the solution in the question, I suspect a more general type is not allowed. \$\endgroup\$ Feb 13, 2014 at 12:31
  • 8
    \$\begingroup\$ If a more general type is allowed, why not f = id? \$\endgroup\$
    – Tom Ellis
    Feb 13, 2014 at 13:18
  • 7
    \$\begingroup\$ In fact if a more general type is allowed then f = f is a solution, so I guess the conditions on the type are very important! \$\endgroup\$
    – Tom Ellis
    Feb 13, 2014 at 13:56
  • 4
    \$\begingroup\$ A more general type is not allowed, your assumptions were correct. \$\endgroup\$ Feb 14, 2014 at 9:28
  • 1
    \$\begingroup\$ If you're allowed to import Control.Applicative, you can replace const by pure, which is one character less. \$\endgroup\$
    – bennofs
    Feb 14, 2014 at 23:08

3 Answers 3


Your example can be shrunk by getting rid of the anonymous function on the right-hand side:

f a b x = snd ([a,x],b)

This works because the type a -> b -> a -> b is equivalent to a -> b -> (a -> b) in Haskell.

  • 4
    \$\begingroup\$ Slightly shorter modification: f a b x = snd (f x,b) \$\endgroup\$
    – Ed'ka
    Feb 14, 2014 at 4:40

The function f _=(.f).const is actually of a more general type than f :: a -> b -> (a -> b), namely f :: a -> b -> (c -> b). If no type signature is given, the type inference system infers a type of f :: a -> b -> (a -> b), but if you include the type signature f :: a -> b -> (c -> b) with the exact same definition, Haskell will compile it without issue and will report consistent types for the partial applications of f. There is probably some deep reason why the type inference system is stricter than the type checking system in this case, but I don't understand enough category theory to come up with a reason as to why this should be the case. If you are unconvinced, you are welcome to try it yourself.

  • \$\begingroup\$ might be like the case of f a b = f a a. it infers to be of type a -> a -> b although it complies with the type a -> b -> c. it is because if f is not given a type it can only use itself monomorphically. \$\endgroup\$ Dec 27, 2014 at 22:07
  • \$\begingroup\$ i don't think this should matter though \$\endgroup\$ Dec 27, 2014 at 22:07

Given ScopedTypeVariables, I came up with this:

f (_::a) b (_::a) = b

If you shrink down both my function and yours, mine is a hair shorter:

f a b x=snd([a,x],b)

Of course, you're probably not allowed to rely on ScopedTypeVariables :P.

  • 4
    \$\begingroup\$ This is not as short as f _=(.f).const (due to Sassa NF). Which also doesn't need ScopedTypeVariables. \$\endgroup\$ Feb 13, 2014 at 12:07
  • \$\begingroup\$ Hmm, I initially thought this would require the first and third arguments to be lists... \$\endgroup\$ Feb 13, 2014 at 12:29
  • \$\begingroup\$ @ChrisTaylor: Too much OCaml on the mind? :) \$\endgroup\$ Feb 13, 2014 at 12:30
  • \$\begingroup\$ Hah, must be! ;) \$\endgroup\$ Feb 13, 2014 at 12:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.