In the context of some putative, bizarre, and quite possibly inconsistent world of idealized functional programming, an imaginary function is an object that, while not necessarily a higher-order function, when applied, yields a function.
add as an example of a function. The following statement is tautological,
or at best metacircular, but demonstrates how we will use equality and an Erlang-like syntax
for functions in this rest of this explanation explanation.
add = fun(X, Y) -> add(X, Y)
Now consider two things called
thunk. It is probably
best to think of them as operations on functions, rather than functions themselves. But
for simplicity we'll define them like we define functions. They could be defined as:
apply = fun(F) -> F() thunk = fun(F) -> (fun() -> F)
From the following example, we can conclude that there are cases where
is the inverse of
apply(thunk(add)) = add
And from the following example, we might conclude that there are cases where
is the inverse of
thunk(apply(thunk(thunk(add)))) = thunk(thunk(add))
So in the putative, bizarre, and quite possibly inconsistent world of idealized functional programming where the concept of imaginary function lives, we will not stop to question those observations, we will just go ahead and say apply and thunk are always inverses of each other.
So, the following equality also holds:
thunk(apply(add)) = add
In the above example,
apply(add) represents an imaginary function.
(Side note: this is not necessarily the same thing as a "regular" appplication of
add(2,3). However, if
add had arity zero, I think we'd expect the definitions to coincide, although I don't offhand see how they could.)
There are many possible levels of imaginariness, as the following also holds:
thunk(thunk(thunk(apply(apply(apply(add)))))) = add
This concludes my description of imaginary functions. All that remains is to make this world of idealized functional programming no longer putative, by finding a definition for it, whether consistent or not.