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

  • \$\begingroup\$ If a more general type is allowed: f = const const. \$\endgroup\$ – hammar Feb 13 '14 at 12:22
  • \$\begingroup\$ @hammar: or f _ b _ = b, but, given the solution in the question, I suspect a more general type is not allowed. \$\endgroup\$ – Tikhon Jelvis Feb 13 '14 at 12:31
  • 6
    \$\begingroup\$ If a more general type is allowed, why not f = id? \$\endgroup\$ – Tom Ellis Feb 13 '14 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 '14 at 13:56
  • 3
    \$\begingroup\$ A more general type is not allowed, your assumptions were correct. \$\endgroup\$ – Radu Stoenescu Feb 14 '14 at 9:28

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.

| improve this answer | |
  • 4
    \$\begingroup\$ Slightly shorter modification: f a b x = snd (f x,b) \$\endgroup\$ – Ed'ka Feb 14 '14 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.

| improve this answer | |
  • \$\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\$ – proud haskeller Dec 27 '14 at 22:07
  • \$\begingroup\$ i don't think this should matter though \$\endgroup\$ – proud haskeller Dec 27 '14 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.

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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