I think it would be fair to say that many students in the starting lessons of general topology get a bit puzzled by the definition of continuous functions when they first encounter it:

Any function $f : X \rightarrow Y $ is continuous if the pre-image $f^{-1}(A)$ of every open set $A$ in $Y$ is open in $X$.

Doesn't it feel like the definition is backward? Shouldn't a continuous function send open sets to open sets instead to preserve structure? Well, functions which do that are called open functions (commonly open maps).

While we learn that continuity and openness are different conditions, some natural questions arise:

1. What do they convey?
2. How are they different?

Even though textbooks contain counterexamples to clarify that they do not imply each other, in many pedagogical settings the lesson ends with a stern warning to not get confused between the two without providing any intuition as to why they are so different.

This post is a mostly non-rigorous intuitive attempt to do that.

We start with some thoughts on the simple real line and then see some general reasons as to why continuity is not just openness.

Continuity in Real Line

Take the good-old $\epsilon-\delta$ definition of continuity:

A function $f : \mathbb{R} \rightarrow \mathbb{R}$ is continuous at a point $c$ if for each $\epsilon \gt 0$ there exists a $\delta \gt 0$ such that $$ |x - c| < \delta \implies |f(x) - f(c)| < \epsilon $$

It first starts with an $\epsilon$ room around the image $f(c)$ and then says: no matter how small an $\epsilon$ one chooses around the image $f(c)$, there must exist a $\delta$ room around $c$ such that every point in it must map inside the $\epsilon$ room.

We can see that this definition would prohibit any jumps. Take the step function which takes the value $-1$ at all $x < 0$ and $1$ at all $x \geq 0$. We can find a room $(1 - \epsilon, 1 + \epsilon)$ around $f(0)$ and easily verify that it is impossible to find a $\delta$ room around $0$ which would map completely inside this target.

The discontinuity occurs because the step function tears the domain at $0$ to map one half of the domain to $-1$ and the rest of the domain to $1$. It is akin to tearing a strip of paper which represents the number line and mapping one part to $-1$ and another to $1$. At the risk of losing some rigour, it might be helpful to rely on this analogy as a ladder to develop intuition.

Before we move forward, let's ponder one minor point.

It is common in intuitive explanations to hear that continuity means “a small change in the input produces only a small change in the output.” This is correct if we are careful about what it means, but it is best not to lean too much on this framing: it reads as if we start in the domain and push forward. This hides the fact that the order in which we pick the two rooms matters a lot.

Suppose we flip it, so that we pick the room around $c$ first and only ask for some room around $f(c)$ to catch the outputs:

A function $f : \mathbb{R} \rightarrow \mathbb{R}$ is continuous at a point $c$ if for each $\epsilon \gt 0$ there exists a $\delta \gt 0$ such that $$ |x - c| < \epsilon \implies |f(x) - f(c)| < \delta $$

This is the same definition as before but we've just switched the $\epsilon$ and $\delta$ in the condition. Now we choose an $\epsilon$ and try to say that if $x$ stays within the $\epsilon$ room then $f(x)$ must stay in the $\delta$ room.

But since a function does not have to map to every point in the $\delta$ room, this distorted definition does not do anything useful. We can always satisfy this definition by taking a big enough $\delta$.

This shows that the task of finding a $\delta$ to constrain $x$ so that $f(x)$ is constrained really does tell us something about the function. But finding a $\delta$ to constrain $f(x)$ given that $x$ is constrained is not really a condition at all. This happens because a function by definition must map every point in its domain somewhere but is not obligated to cover any point in the codomain

The actual definition works because it runs the other way: the codomain sets a target, and the domain must find a room small enough to land inside it. A function must map every point of its domain somewhere, but it is not obligated to cover any point in the codomain. So making a room in the codomain big enough to contain the outputs costs nothing, while shrinking a room in the domain until the outputs fit inside an arbitrary target is a genuine condition.

Coming back to the point in discussion, the definition of an open map is also very similar to our wrong $\epsilon-\delta$ definition, but even more restrictive. For a map to be open, every open set $A$ must map to some open set $B$ in the codomain.

As mentioned before, this looks like a nice condition, but note again what it proposes: the image of every open set $A$ must be some open set $B$. This means that every point in the open set $B$ must be mapped to by some point in $A$.

This has a few unintended consequences which make open maps quite restrictive but at the same time do not ensure continuity in general. Let's see.

Open is Too Restrictive

If a function $f$ must map every single $A$ to some open set $B$, it must ensure that whatever $B$ happens to be, it is covered in full.

This immediately disallows any functions which stay constant in any small interval in their domain. If the function is constant in any interval $(a, b)$, then we can find a smaller open interval $(a + \epsilon, b - \epsilon)$ ($\epsilon < b - a$) which would map to a single point in the codomain, which obviously happens to be not open.

But constant functions are as benign a function as possible. They are certainly continuous, but it looks like they cannot be open. To borrow the analogy, this really means that for a function to be open, squishing to a point is not allowed, as the function must spread to the whole of $B$ for every $A$, whatever open set $B$ happens to be.

Take another example, say, $f(x) = x^2$. Though this is also a well-behaved continuous function on $\mathbb{R}$, it is not an open map. If we take an open interval around $0$, say $(-1, 1)$, we can see that the image of this open interval is $[0, 1)$, which is clearly not open in $\mathbb{R}$. This function is also continuous, but not open.

If we stretch the analogy further, we can see that $x^2$ creases the domain at $0$ in order to create a minimum and revert back.

We can see that for a function to be open, both squishing and creasing of the domain are not allowed while mapping into the codomain.

This means that any nice continuous function which attains an extremum and changes direction in its domain ceases to be open. It is a common exercise in analysis to prove that any continuous function $f : \mathbb{R} \rightarrow \mathbb{R}$ which happens to be open must be strictly monotonic.

If $f$ is continuous and open on an interval $I$ but not strictly monotonic, then there would exist $$ u < v < w $$ in $I$ such that $f(v)$ is not strictly between $f(u)$ and $f(w)$. This means that $f$ would have a local extremum at some interior point in $I$. And we have already seen that we can take a sufficiently small open interval around an extremum which maps to a half-open interval. This would mean $f$ is not open.

So, it is clear that an open map is not a useful way to ensure continuity in functions, as it disallows many nicely behaved continuous functions.

But let's look at this question from another angle: does the restriction of openness rule out any discontinuities?

It turns out the answer is yes, but mostly accidentally, I think.

It is easy to see that any open map would avoid simple isolated discontinuities like a step function. Since the step function we supplied above is constant on either side of the jump, it is obviously not open. But if we look at a strictly monotonic map with a discontinuity, say

$$ f(x) = \begin{cases} x & \text{if } x < 0 \\ x + 1 & \text{if } x \geq 0 \end{cases} $$

We can see that it also fails to be open. For the interval $(-1, 1)$, the image is $(-1, 0) \cup [1, 2)$, which is clearly not open.

If we push this line further, we can convince ourselves that $f$ cannot possibly have isolated discontinuities, by which we mean that $f$ cannot be discontinuous at any $c$ while still being continuous on some $(c-\epsilon, c)$ and $(c, c+\epsilon)$.

To see why that is true, note that $f(c)$ would lie either inside or outside the open images of these two intervals.

It cannot lie outside as an isolated point, because then it would sit by itself in the image of $(c-\epsilon, c+\epsilon)$, making that image non-open as we have seen before.

But if it lies inside the image of either side interval, say the left interval $(c - \epsilon, c)$, we can just find a smaller interval around $c$ to exclude the one point in $(c - \epsilon, c)$ which happened to also map to $f(c)$.

Strict monotonicity ensures that $f$ attains the value $f(c)$ only once inside $(c - \epsilon, c)$. But with the smaller interval, $f(c)$ would be back to being an isolated point outside both (shrunk) images, and we have already ruled that out.

So $f(c)$ can only sit right at the shared edge between the open images, which just means $f$ is continuous at $c$.

Open is Possibly Discontinuous

It looks like disallowing a good chunk of functions also disallows simple types of discontinuity. But openness does not disallow all types of discontinuities.

We already saw that isolated discontinuities are disallowed if surrounded by continuity.

So, we have seen that open maps are good at ensuring that the function does not squeeze or crease the domain in ways that introduce boundaries in the images. But open maps are not very helpful in ensuring that the function does not tear up the domain. While simple tearings like isolated jumps are disallowed because they inevitably introduce boundaries, there are ways to construct open maps which defy continuity in pathological ways.

Since open maps only ensure that open sets map to open sets, if we can somehow manage to map every single open set to the entire real number line, the function does become open but would not be continuous. A famous example is the Conway base-13 function. It is based on an idea which roughly works like this:

1. In Conway's construction, the number $x$ is written in base 13 with the usual base-10 digits and other symbols like $+$, $-$, and $.$
2. Now every number $x$ can be mapped to either $0$ or some other real $r$ based on some rule.
3. The rule looks like this: if the number when written in base 13 has a tail which looks like a valid base-10 real, then it is mapped to that real. If not, then it is mapped to $0$.
4. Take some number $x$ which when written in base 13 looks like +-492+1-2+3.14159...; then this number would get mapped to $\pi$.
5. But if the base-13 expansion never has a tail which looks like a valid real, say +-492+++..., it is mapped to $0$.

Now, somewhat strangely, this function does happen to be an open map. If we take any interval $(a, b)$, no matter how small, we can show that its image under the above function is the entire real line $\mathbb{R}$ (which is open in $\mathbb{R}$). Take any arbitrary real $r$; all we need to do is to prefix a valid base-13 head to produce a number $c$ such that:

1. $c \in (a, b)$
2. the tail of $c$ when written in base 13 is equal to $r$

Since the head is the most significant part of the number and can be arbitrarily long before the tail begins, we can always find a $c$ which satisfies these. But even though this function is open, it is obviously not continuous.

So, openness disallows simple enough tears in the number line, because they introduce boundaries in some image and destroy openness. But if we tear every single point in every single open interval and scatter them like dust particles over the entire number line, then openness is not violated, as the whole real number line does not have any boundaries.

Beyond the Real Line

So, now we have some idea of what open maps must be like on the real line. But what about a general topology where there are no metrics or intervals? What do continuity and openness mean in a space with a vague notion of distance or proximity, or none at all?

Before we go there, we must notice that open sets in a general topology do not represent any property, unlike on the real line. In an unspecified general context, open sets are just sets which behave in a certain manner vis-à-vis set-theoretic operations. Any collection of subsets can be the open sets of a topology as long as it contains the empty set and the whole space, and is closed under arbitrary unions and finite intersections. This is how the topology is defined in the first place.

Now, the curious thing about the pre-image of a function is that it plays very, very well with set-theoretic operations. For any function $f : X \rightarrow Y$, any subsets $A$ and $B$ of $Y$, and any family of subsets $A_i$ of $Y$:

• Union: $f^{-1}\left(\bigcup_i A_i\right) = \bigcup_i f^{-1}(A_i)$
• Intersection: $f^{-1}(A \cap B) = f^{-1}(A) \cap f^{-1}(B)$
• Difference: $f^{-1}(Y - A) = X - f^{-1}(A)$

Regardless of the function, pre-images faithfully preserve unions and intersections. This is largely due to the fact that a function by definition must map any point in the domain to a unique point in the codomain.

Note from the above equations (together with $f^{-1}(\varnothing) = \varnothing$ and $f^{-1}(Y) = X$) that the set of pre-images in $X$ of all open sets in $Y$ under $f : X \rightarrow Y$ already fulfills the condition of being a topology on $X$. This means that even before we define continuity or openness, pre-images automatically induce a topology on $X$ just by virtue of their properties.

Said differently, if we consider the sets of points which got transformed into open sets in the codomain $Y$, we already know that they would form a valid topology. Continuity only requires that they must have come from the topology already endowed on $X$ itself.

This begins to shed some light on what continuity might be trying to portray. It shows that whatever structure $Y$ has in terms of open sets, if we try to pull back the structure along the function to $X$, we just need to ensure that a similar or finer structure is available in $X$.

But when we talk about images, things are not quite smooth. We started by thinking that images might propagate or push the structure from $X$ to $Y$, but alas, that is not at all true. Images simply don't play well with set-theoretic constructions. Unions still work, but intersections don't. $f(A \cap B)$ is not necessarily equal to $f(A) \cap f(B)$, because functions can map multiple points in the domain to the same point in the codomain. Also, $f(X - A)$ is not equal to $Y - f(A)$ in general.

So, even if we could ensure that open sets propagate from $X$ to $Y$ via images of open maps, we would never be able to ensure that they induce a topology on $Y$ from the topology of $X$ itself.

This is the reason that imposing conditions on the image of a function does not afford us any special behaviour when it comes to ensuring continuity.

If we try to circle back to the analogy of tearing, which continuity is supposed to disallow, we see that pre-images are the right choice. If we take a simple step function on $\mathbb{R}$ which jumps at some $c$ in the domain to $f(c)$ in the range, then the pre-image of any sufficiently small open interval $(f(c) - a, f(c) + a)$ would obviously be outside the usual topology of the domain $\mathbb{R}$ (as it is the closed ray $[c, \infty)$). This just means that the induced topology from all the pre-images of the step function contains at least one element different from the usual topology on $\mathbb{R}$. This makes the pulled-back set fundamentally alien to the original topology of $\mathbb{R}$. This is exactly the tear in the domain which creates a set-theoretic boundary in the pre-image that the original domain topology never possessed. It is detected when the induced topology on the domain is found to be different from, and irreconcilable with, the endowed topology.

Two Mindsets

When we first study topology, our natural impulse is to think of functions as transformations which push the structure of a space forward onto another. That is why requiring open sets to map to open sets might feel like the only logical way to preserve structure.

But as we have seen, open images as a condition are neither necessary nor sufficient, for ensuring continuity. The condition disallows benign smooth behaviour like local extrema or constancy, but at the same time allows pathological maps to tear and scatter open sets everywhere.

Continuity instead works under a pull mindset under which we ask: does the domain possess enough structural resolution to make sense of the open sets in the codomain? If the answer is yes, the function is continuous. This is why, if we have the finest topology on the domain or the coarsest topology on the codomain, all functions become continuous.

But this should not mean that open maps are useless altogether. If a function which is both continuous and bijective (one-one onto) also happens to be open, then its inverse becomes continuous, which allows us to mark two topological spaces as structurally identical (homeomorphic).

But taken separately, open and continuous maps measure two entirely different features of a transformation:

Continuity prevents tearing by ensuring the structure of the codomain can be pulled back into the topology of the domain. Openness prevents squishing and creasing by ensuring the room of the domain is distributed adequately across the image.

Here is a simpler version of the famous repmin puzzle from Richard Bird's arsenal of functional tricks: Given a non-empty array of numbers a, you have to find the smallest number m and replace every element of a with m in a single traversal.

Naive Non-Solution

It is straightforward to build a naive non-solution which calculates the minimum value of a in one pass and then mutates a in another pass:

function findMin(a) {
  let m = a[0]
  for (let i = 0; i < a.length; i++) {
    if (a[i] < m) {
      m = a[i]
    }
  }
  return m
}

function replaceMin(a, m) {
  for (let i = 0; i < a.length; i++) {
    a[i] = m
  }
}

const m = findMin(a)  // Pass #1
replaceMin(a, m)      // Pass #2

The question is: how do we perform these temporally dependent tasks in a single pass? That is, how do we go through a to replace all its elements with m but somehow also calculate m at the same time?

Basically, we need to traverse a to calculate m and simultaneously replace its elements with some value x which we can guarantee is going to be the minimum value.

But wait, won't that require sending a message to the present from the future?

So, is it necessary to invent a time machine to solve this puzzle? Or could we do with something more modest: say, a simple function and a tiny leap of faith?

A Function as an Unevaluated Value

To see how a simple function can help us, please note that the seemingly temporal dependency arises only because replaceMin(a, findMin(a)) forces the traversal in findMin before the replacement in replaceMin.

If we could just find a way to represent the minimum value not as a Number in JavaScript but as a function instead, the temporal dependency would vanish because a function doesn't need to be evaluated immediately. We can just replace every element of a with a function which would evaluate to the minimum value later. This function is then a proxy for m which delays the need to actually calculate m when we enter replaceMin.

Let's do this with a function findAndReplaceMin which calculates m but also replaces the elements of a by some as-of-yet unrelated function xf in a single pass:

function findAndReplaceMin(a, xf) {
  let m = a[0]
  for (let i = 0; i < a.length; i++) {
    if (a[i] < m) {
      m = a[i]
    }
    a[i] = xf
  }
  return m
}

Note that findAndReplaceMin receives xf as an argument and replaces every element of a with it. We still need to choose xf so that every occurrence of xf eventually yields the minimum value, even though that minimum has not yet been computed.

This seems like a problem. We're still stuck in a situation where computing m requires calling findAndReplaceMin with xf, but xf must already know how to produce m before findAndReplaceMin has computed it.

Make Evidence for Faith

This seems like a real problem until we realise that we can bootstrap the evidence for our faith by saying this:

let m = findAndReplaceMin(a, () => m)

This seems paradoxical: how can m be used in its own definition?

The answer is subtle: we are NOT using m to calculate m but only denoting m in a function which calculates m independently of the denotation.

More precisely, the closure () => m captures the variable m, which has not been initialised yet, without forcing its evaluation, which would happen only when we say xf(). And if you look carefully, we take care not to do that anywhere inside findAndReplaceMin (more on this in a bit).

When the line let m = findAndReplaceMin(a, () => m) is executed, it does two separate tasks in one single pass:

1. Calculate the minimum value by traversing a and bind it to m
2. Replace every element of a with the function () => m (without evaluating the function)

Contrast the line above with the obviously invalid declaration let m = m, which immediately attempts to read the value of m before it has been initialised.

By comparison, let m = findAndReplaceMin(a, () => m) never reads m during the construction of the closure. The expression () => m merely records how to obtain m in the future. The actual lookup is postponed until the function is called.

Note that after findAndReplaceMin has run, a is populated by functions and not Numbers. So, when any element of a is needed, we get it by calling a[i](), which reads the value bound to m. Note that this doesn't need to run findAndReplaceMin again because m is already bound to the minimum value from Step 1.

In functional parlance, writing this self-referential declaration is close to what is called tying the knot. It refers to the circular reference to m, which we fill from findAndReplaceMin in the future, but which we can still use inside findAndReplaceMin in the present if we take care not to inspect or evaluate it.

The key to this illusion of time travel is the assignment a[i] = xf without inspecting xf. We cannot afford to poke xf (say by doing xf()) inside findAndReplaceMin, because that would try to read m while we are still in the middle of computing it. JavaScript doesn't play along: it throws a ReferenceError on the spot, complaining that m cannot be accessed before initialisation.

I should reiterate that no law of physics is being broken here and no information is actually travelling backwards in time. We instinctively think of computation as a sequence of steps: first compute the minimum, then replace the elements. But tying the knot invites us to think equationally instead. Rather than saying let me calculate m first, we say here is how I'd like m to be defined given findAndReplaceMin, with the added benefit that the definition itself can be self-referential if we build it carefully.

We've almost solved this puzzle, but you might now complain: we were asked to create an array of Numbers but ended up creating an array of functions instead.

And the answer is that with standard primitives, we can't solve this perfectly in JavaScript without leaving behind an array of functions. (We could maybe pull off a solution using some advanced object metaprogramming, but that's probably a topic for another blog post!)

The Real Lazy Evaluation

To see how we can do exactly what we set out to, we look at a language where delayed evaluation is built in: Haskell.

Let's see what findAndReplaceMin would look like in Haskell:

findAndReplaceMin :: [Int] -> Int -> (Int, [Int])
findAndReplaceMin [y]     x  = (y, [x])
findAndReplaceMin (h : t) x  = (min g h, x : t')
  where (g, t') = findAndReplaceMin t x

let (m, b) = findAndReplaceMin a m

It almost mirrors the JavaScript logic, but recursively and immutably.

After findAndReplaceMin has run, the list b contains Ints in Haskell. But the same is not possible in JavaScript. Why?

The main reason is that in Haskell, we do not need to rely on closures to delay evaluation because values are lazy by default.

What that means in practice is that Haskell does not evaluate expressions just because they are passed as arguments or stored inside data structures. Instead, expressions are represented as unevaluated values (called thunks) and evaluated only when their values are demanded in some calculation. This evaluation strategy is known as call-by-need evaluation. An expression like findAndReplaceMin a m can be written without worrying about m being evaluated before findAndReplaceMin has finished. So, we don't need to resort to tricks like () => m just to delay evaluation of m. The expression bound to m remains unevaluated until some operation (mostly pattern-matching, or some function which needs m, like + or show) actually demands its value.

Compare this to JavaScript, where if we write findAndReplaceMin(a, m), both a and m would be evaluated before being passed to the function, which is why we need to wrap m inside () => ... to prevent JavaScript from poking. This style of evaluation is called call-by-value evaluation and is common in languages like C, Python, and JavaScript.

Also, tying the knot is relatively easier in Haskell. In Haskell, we can just write m on both sides of let (m, b) = findAndReplaceMin a m. A similar attempt in JavaScript is bound to fail, which is also why we took care to hide m inside () => m. But Haskell can construct cyclic graphs of thunks. The self-reference in let (m, b) = findAndReplaceMin a m does not require the runtime to know the value of m immediately. Instead, it creates a network of dependencies in which m and b can mutually refer to each other. Laziness ensures that these references are only followed when their values are actually needed.

Don't Peek Too Soon!

So it turns out we didn't need a time machine after all: just a function, a carefully deferred lookup, and the discipline not to peek too soon. But more importantly, in both languages, the trick explicitly relies on the same leap of faith: while lazy evaluation (Haskell) and the wrapper lambda (JavaScript) prevent automatic evaluation by the runtime, we ourselves cannot afford to peek into them (by pattern-matching on m in Haskell or calling xf in JavaScript) before findAndReplaceMin finishes execution.

If we get too impatient and lose faith, the knot comes undone in both languages. JavaScript refuses outright with a ReferenceError, while Haskell chases its own tail into an infinite abyss of doubt till time ends, unless GHC notices the loop first and gives up with a terse <<loop>>!

Let's try to solve a simple enough puzzle in JavaScript: You have to write a function fact(n) which calculates the factorial of a number n, but you cannot use loops (for, while, etc.), recursion, or even declarations (let, const, etc.).

Non-Solution: Direct Recursion

We start with a canonical recursive non-solution to know what we're aiming for, in terms of behaviour:

function fact(n) {
  if (n === 0) {
    return 1
  }
  else {
    return n * fact(n - 1)
  }
}

This is a non-solution because we cannot use recursion, which means we cannot call the function fact from inside the definition of the function fact.

Non-Solution: Mutual Recursion

So, running for loops or calling fact from itself is not allowed. Then, what should we do? Can we call fact from some other function and try to arrive at the same behaviour?

After some thinking, we can write a function factf which calculates factorial but doesn't call itself:

function factf(n) {
  if (n === 0) {
    return 1
  }
  else {
    return n * factg(n - 1)
  }
}

function factg(n) {
  if (n === 0) {
    return 1
  }
  else {
    return n * factf(n - 1)
  }
}

This works. factf(n) does calculate the factorial. So, are we done? Well, we did avoid an explicit call to factf inside factf, but it'd be a lie to say that this doesn't use recursion.

This solution calls for a new rule: mutual recursion is also not allowed.

Non-Solution: Recursion via Indirect Self-Reference

But, can we still learn something from the previous attempt? We know that if we decide to avoid loops, we definitely need to emulate a call to something like fact inside fact. What if we don't call fact inside fact directly, but instead define a generator function factgen and pass it a function which gets called instead?

function factgen(self, n) {
  if (n === 0) {
    return 1
  }
  else {
    return n * self(self, n - 1)
  }
}

let fact = n => factgen(factgen, n)

To see how it works, take fact(4). It is just factgen(factgen, 4), which evaluates to 4 * self(self, 3), which is just 4 * factgen(factgen, 3), which reduces to 4 * 3 * factgen(factgen, 2), and so on. Every factgen(factgen, n) call essentially becomes n * factgen(factgen, n - 1) until n becomes 0.

It seems like we've solved our puzzle:

1. fact did not call itself in its own definition (explicit recursion).
2. fact also did not call any other function which called fact indirectly (mutual recursion).

But alas, we still leaned on declarations. factgen is a named function, and fact only works because it can refer to factgen by name and hand it to itself. And if we look closely at our challenge, we should not use a declaration.

If we really vowed to let go of declarations, we should avoid using function too. This calls for another rule: no declarations at all, including function.

We'd use only anonymous functions like (x, y) => { ... } in our solution.

Recursion is Self-Reference

But like before, let's see if we can get some intuition from the definition above. If we zoom in on the recursive part, we see that self(self, n) has a curious property. Evaluating it does not eliminate the self-reference. Instead, it eventually produces another call involving the same pattern, namely self(self, n - 1) embedded inside a larger expression. The argument changes, but the self-application survives. This is not even specific to the definition of fact given here. If, say, there were a function f defined like this:

function f(g, n, s) {
  console.log(s)
  if (n < 10) {
    g(g, n + 1, s)
  }
}

and it were called like this: f(f, 0, "hello, world"), we'd get "hello, world" printed repeatedly until n reaches 10 (if stack size allows). That's basically a while loop.

So, our venture teaches us that the pattern g(g, ...) captures the core mechanism needed to create recursion. It results in itself when it executes, which allows it to reuse the same behaviour with different inputs to emulate iteration.

Self-Replication without Self-Reference

Let's see if we can extract this pattern into a function to gain more insight:

let rep = x => x(x)

(Don't worry about the let; this is not an attempt at solving the challenge and we'd remove it later.)

Clearly, rep doesn't do anything in particular. It just takes a function x and calls x with argument x. But something interesting happens when we call rep with itself as an argument. If we reason purely in terms of expressions and forget evaluation for a moment, then rep(rep) rewrites to rep(rep) again.

(Operationally, however, a JavaScript engine attempting to evaluate this expression would recurse forever and eventually overflow the stack. We'd handle this problem later. For now, we are interested only in the equational behaviour of the expression.)

In other words, if written without rep, the code:

(x => x(x))(x => x(x))

reduces to itself. Please note that we just obtained self-application without loops, recursion, or declarations. We just used an anonymous function and literally wrote the function twice by hand.

But what good is self-replicating code like rep if we can't use this machinery to do some real task, like calculating the factorial? To get something useful with rep, we'd need to expand on this idea.

How about we do the obvious and stick a function, say h (assumed to be in scope), inside the definition of rep:

let rep = x => h(x(x))

Now, something even more interesting happens if we reduce rep(rep). (Again, we just mean reduction in the equational sense, not how it would run on the system.)

rep(rep) just reduces to:

(x => h(x(x)))(x => h(x(x)))

which is nothing but:

h((x => h(x(x)))(x => h(x(x))))

which, if we look closely, is just h(rep(rep)) expanded. In other words, rep(rep) reduces to h(rep(rep)) with our new definition of rep.

This is more interesting. Now we not only have replication, but we can run some function on the result. This is very close to the recursion we're looking for.

Enter Y

What if we wrap this whole self-replicating machine inside a function Y which accepts a payload h:

let Y = (h) => {
  let rep = x => h(x(x))
  return rep(rep)
}

The Y is basically a higher-order function which takes a function h and returns the self-replicating code we wrote before, parametrised by h.

But there are two problems now:

1. It is not clear how to use Y to emulate recursive behaviour.
2. As many of you might be complaining now, the way everything above is written, from rep to Y, it won't even work because it would never stop evaluating.

Let's tackle the first problem first as it looks easier. Assume that the second problem is solved, i.e., assume we have some way through which we can delay the call to rep(rep) till just the right moment. Now, given a delayable Y, how then would we come up with the factorial function?

To see what Y does, let's see what Y(f) means. If evaluation can be delayed at will, we can see that Y(f) would reduce to rep(rep), which would just evaluate to f(rep(rep)), which is identical to f(Y(f)) in terms of behaviour.

So Y(f) reduces to f(Y(f)), which reduces to f(f(Y(f))), and so on. Assuming it exists, let's call the result of Y(f) p. What we've shown is that p satisfies:

p = f(p)

Feeding p back through f gives p again.

An object with that property is called a fixed point of f. So Y(f) is just a fixed point of f.

Now admittedly, this is just a tidy definition and not yet a working program. Let me get there via a short detour, on the promise that we're close.

Fixed Points and Recursion

Let's go back to our factgen from earlier and try to write a curried version which takes only a single argument and returns a function:

function factgen(factaux) {
  return n => {
    if (n === 0) {
      return 1
    }
    else {
      return n * factaux(n - 1)
    }
  }
}

This factgen is the curried analogue of the earlier factgen. It takes a function factaux and returns a function which takes a number n and returns its factorial by calling factaux internally.

If the declaration let fact = factgen(fact) worked in JavaScript, it would define the factorial. Alas, JavaScript refuses to run it: it evaluates the right-hand side first, and it cannot pass fact into factgen before fact has finished being initialised. (JavaScript is inadvertently applying the rules of the challenge for us here.)

But like before, every failed attempt is an opportunity to look for a new idea. In this case, if we observe closely, we can see that the equation fact = factgen(fact) describes something familiar about fact. Going back to our discussion of Y, if we think of fact as p and factgen as f, then a curious fact reveals itself: fact is nothing but a fixed point of the function factgen!

Note that what was said above is not dependent on the details of the factorial function, which sit cozily inside factgen, untouched by our discussions on fixed points. In fact, the following observation is true for all recursive functions:

Every recursive function (like fact) can be expressed as a fixed point of an appropriately defined function (like factgen).

To see why, note that any function satisfying fact = factgen(fact) behaves exactly like the recursive fact we wanted to define in the first place: factgen(fact) is just a factorial whose recursive calls have been delegated to fact itself.

While JavaScript rejects this definition, what if we had a way to calculate the fixed point of factgen which doesn't involve a call to the as-of-yet undefined fact?

Re-enter Y

We do. Y(factgen) is nothing but a fixed point of factgen. So we could now just define fact like:

function factgen(factaux) {
  return n => {
    if (n === 0) {
      return 1
    }
    else {
      return n * factaux(n - 1)
    }
  }
}

let fact = Y(factgen)

We've solved our main problem: fact is no longer defined in terms of itself but as the fixed point of factgen. (Note that we're still using let and function, which we'd get rid of in a while.)

Now that we have a solution using Y, let's come to the second problem. So we assumed that we could delay the repeated evaluation of Y till it's needed. But how can we do that?

Note that in JavaScript, the arguments of a function are evaluated before the function is called. In technical terms, this is known as eager (or call-by-value) evaluation. When we try to evaluate Y(factgen), it reduces to factgen(Y(factgen)). But this never hands control to factgen, because the argument Y(factgen) must be fully evaluated first, which triggers the exact same loop, looping forever before a single line of factgen actually executes.

The Lazy Cousin

What if there was a simple way to introduce delay in the evaluation of a value like Y(factgen)? How about trying to wrap it inside another function instead?

We tweak Y by wrapping the argument x(x) of the call h(x(x)), turning it into h(v => x(x)(v)):

let Z = (h) => {
  let rep = x => h(v => x(x)(v))
  return rep(rep)
}

If we look closely, Z is almost identical to Y. The only difference is that the self-application is wrapped inside another function: v => x(x)(v). This wrapping postpones the self-application until it is actually needed.

But conceptually, the behaviour remains the same.

Z(f) evaluates to rep(rep), which expands to f(v => rep(rep)(v)).

Now, the function v => rep(rep)(v) is not literally the same object as rep(rep). The difference is that it delays the self-application until an argument is supplied. But for our purposes, v => rep(rep)(v) plays the same role as rep(rep). Whenever it is eventually called, it re-enters the same self-referential computation that rep(rep) would have triggered immediately. The difference is merely one of timing.

Now, let's get back to factorial. Amazingly, Z is so much like Y that we can just replace Y by Z in our definition and it works.

Z(factgen) evaluates to factgen(v => rep(rep)(v)), which is just the function:

n => {
  if (n === 0) {
    return 1
  }
  else {
    return n * (v => rep(rep)(v))(n - 1)
  }
}

Here (v => rep(rep)(v))(n - 1) is just rep(rep)(n - 1), and rep(rep) expands back to factgen(v => rep(rep)(v)). The self-reference is recreated, but the computation is delayed because the lambda v => rep(rep)(v) doesn't need to be reduced further until it is applied to an argument.

So calling this on 4 gives 4 * rep(rep)(3), which gives 4 * 3 * rep(rep)(2), and so on down to n === 0, where the recursion bottoms out at 1 and the else branch is finally skipped.

Here is a visual trace of the evaluation:

Z(factgen)(4)

factgen(v => rep(rep)(v))(4)

4 * (v => rep(rep)(v))(3)

4 * rep(rep)(3)

4 * factgen(v => rep(rep)(v))(3)

4 * 3 * (v => rep(rep)(v))(2)

4 * 3 * rep(rep)(2)

4 * 3 * 2 * (v => rep(rep)(v))(1)

4 * 3 * 2 * rep(rep)(1)

4 * 3 * 2 * factgen(v => rep(rep)(v))(1)

4 * 3 * 2 * 1 * (v => rep(rep)(v))(0)

4 * 3 * 2 * 1 * rep(rep)(0)

4 * 3 * 2 * 1 * factgen(v => rep(rep)(v))(0)

4 * 3 * 2 * 1 * 1

24

Notice that in the last step, it doesn't matter what the argument to factgen is. No recursion is triggered, and the returned function terminates since n is 0.

So, to conclude, the expression Z(factgen) behaves exactly like a function which calculates a factorial. You can test it by calling console.log(Z(factgen)(4)).

In fancy parlance, the function Y is called the Y combinator. It is a fixed-point combinator: given a function, it produces one of its fixed points.

But the version that actually works in JavaScript is usually called the Z combinator. Conceptually it performs the same task as Y, but introduces an extra layer of indirection so that the construction can survive the eager evaluation strategy.

The End

So, after many an ordeal and digression, we have finally defined a factorial without iteration or recursion. And if you insist, even without declarations:

(f => (x => f(v => x(x)(v))) (x => f(v => x(x)(v)))) (cb => n => (n === 0) ? 1 : n * cb(n - 1))

Case closed.