Below is the function repeat
written using a functional paradigm, such that when called as repeat(square, 2)(5)
it will apply the square
function 2
times on the number 5
, something like square(square(5))
.
def repeat(f, n):
def identity(x):
return x
def apply_n_times(n):
def recursive_apply(x):
return apply_n_times(n - 1)(f(x))
if n < 0:
raise ValueError("Cannot apply a function %d times" % (n))
elif n == 0:
return identity
else:
return recursive_apply
return apply_n_times(n)
def square(x):
return mul(x, x)
With regards to abstraction, I see that repeat(square, 2)
returns an implementation detail in the form of apply_n_times(n - 1)(f(x))
multiple times before providing the actual result.
With regards to encapsulation, for the expression f = repeat(square, 2)
one could mutate the members of function object, for example: f.__name__='garbage'
Does the concept of higher order function
allow supporting abstraction and encapsulation? Because they return the implementation details and provide access for mutation.
Such existing implementations in large software are very tedious to use, as the user has to have an idea of the implementation before using it.
Best Answer
The function returned by
repeat(square, 2)
is not an implementation detail; it's the whole point of callingrepeat
. An implementation detail is something that the caller doesn't need to know about (and in most cases isn't allowed to know anything about either) and that could be changed without breaking any of the caller's code. The caller wants and needs the function returned byrepeat
.It seems to me that you're looking at
repeat
as if its purpose is to give you the result of applyingf
, and that's why you see the fact that it returnsapply_n_times
as an implementation detail. If you only wanted the result of composingf
with itselfn
times, you could have definedrepeat
to take three arguments. But what makes curried functions useful it the fact that you can make use of the in-between functions it creates! E.g.In other words, their purpose isn't to compute the final result, it's to compute a function that can compute the final result. The function returned by
repeat
is a useful thing to have in and of itself.Everything in Python has metadata that can be inspected and modified, and function objects are no exception. Python won't stop you from deeply inspecting and messing with every piece of data in the program. That lets you break almost any abstraction if you choose to do so. So you could say that it's Python that doesn't have very good support for encapsulation. In functional languages a function doesn't "know its name", because asking a function for its name makes about as much sense as asking an integer for its name. Functions don't need names, and if you choose to give them one, they don't need to know it.
But do note that every call to
repeat
produces a new function object, so even if you choose to muck around with it, the changes you made won't affect the return values of other calls torepeat
.