Why higher order procedures?

Question

So if a language provides higher order procedure then I can have procedure that returns procedure. Something like:

(define (Proc a b c)
  (lambda (x) ( #| method body here in terms of a b c and x |# )))

To create new procedure, I would just do something like:

(define ProcA (Proc a1 b1 c1)) ; Would create ProcA that has 1 argument

Similar task could be done in a language which does not support higher order procedure by defining Proc that takes 4 instead of 3 arguments and calling this procedure to define ProcA, like:

(define (Proc a b c x) ( #| method body -- does not return any procedure |# )
(define (ProcA x) (Proc a1 b1 c1 x))

So why is there so much fuzz about higher order procedure? Am I missing something?

Answer 1

It's a good observation that a function that returns another function is the same as a function that takes two arguments. This is called "Currying". Put another way, a function from A to B is proof of a logical implication, that A implies B, or:

A => B.

As you note, if A implies that B implies C, then A and B implies C, or:

(A => (B => C)) <==> ((A, B) => C)

But a higher order function is not necessarily a function that returns another function. A higher-order function is a function that takes another function as its argument. This is an important difference, and HOFs are immensely powerful programming tools.

For example, consider this Haskell function:

map :: (a -> b) -> [a] -> [b]
map f [] = []
map f (x:xs) = f x : (map f xs)

This higher-order function takes a function f and applies it to every element in a list. In languages without HOFs, you would do what this function does with a loop or something similar, but in a language that has HOFs, you can call f for every element in the list with a simple call like this:

map f myList

Sure, control constructs in languages let you approximate higher-order functions, but a language that has higher-order functions lets you invent your own control constructs. Scheme certainly qualifies.

Answer 2

I won't try to recapitulate the argument here, but in Why Functional Programming Matters, John Hughes argues that higher-order functions are useful because they provide more effective ways to "glue together" parts of a program, and thereby they make it easier to reuse code. The examples are in a very old language that is no longer used much, but they are still easy to follow and pretty convincing. Reading John's paper is a good way to get a detailed answer to your question "why is there so much fuzz about higher-order procedures".