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 lean 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 : X \rightarrow Y$ 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 a $\epsilon$ room around the image $f(c)$ and then says: no matter how small $\epsilon$ one chooses around image of $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 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 "close enough points in domain must map to close enough points in codomain". But we need to be a bit more careful about how we formalise this.

Imagine if we mistakenly represent this definition as follows:

A function $f : X \rightarrow Y$ is continuous at a point $c$ if for each $\epsilon$ there exists a $\delta$ 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 the $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 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.

Now, if we look closely enough the definition of open map is also very similar to our wrong $\epsilon-\delta$ but even more restrictive. For a map to be open, every open set $A$ must map to some open set $B$ in codomain.

As mentioned before, this looks like a nice condition but note again what it proposes: 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 by some point in $A$.

This has a few unintended consequences which make open maps quite restrictive but at the same time does not ensure continuity in general.

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, it is covered in the fullest.

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 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. It certainly is continuous, but it looks like it can not 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 whole of $B$ for every $A$ whatever open set $B$ happens to be.

Take another example, say, $f = 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 minima 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 extrema 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 interval $I$ but not strictly monotonic, then there would exist $$ u < v < w $$ in $I$ such that $f(v)$ is not 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 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 a yes, but mostly accidently, I think.

It is easy to see that any open map would avoid any simple isolated discontinuities like a step function. Since the step function we supplied above is constant, 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. We can see that 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$ can not possibly have isolated discontinuities by which we mean that $f$ can not be discontinuous at any $c$ while still being continuous on some $(c-\epsilon, c)$ and $(c, c+\epsilon)$.

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

It can not 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 intervals, say the left interval $(c - \epsilon, c)$, we can just find a smaller interval around $c$ to exclude that one point in $(c - \epsilon, c)$ which happened to also map to $f(c)$.

Strict monotonicity ensures that $f$ attains 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 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 continuities.

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

But the function can still diverge while being open. $\tan(x)$ is a simple example. It diverges at every $x = (2n + 1) * \pi / 2$ but still happens to be open as any open interval in the domain yields either an open interval or a union of two infinite open intervals in the domain.

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 creases, 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 had 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 translated to Base-13 looks like: $$ +-492+1-2+3.14159... $$ then this number would get mappped to $\pi$.
5. But if the Base-13 expansion never had a tail which looked 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. tail of $c$ when written in Base-13 is equal to $r$

Since 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, even though openness disallows simple enough tears in the number line because they introduce creases 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.

Step Out of Reality

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 does continuity and openness mean in a space with vague or no notion of distance or proximity?

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-a-vis set-theoretic operations. Any collection of sets can be open if they preserve under arbitrary unions and finite intersections. This is how the topology is defined in the first place.

Now, the curious thing about pre-image of a function is that it plays very very well with set-theoretic operations. For any function $f : X \rightarrow Y$ and any $A$ and $B$ in $Y$ $$ f^{-1}(A \cup B) = f^{-1}(A) \cup f^{-1}(B) \\ f^{-1}(A \cap B) = f^{-1}(A) \cap f^{-1}(B) \\ f^{-1}(Y - A) = X - f^{-1}(A) $$

Regardless of the function, pre-images faithfully preserve unions and intersections. This is largely due of 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 that the set of pre-images in $X$ of all open sets in $Y$ of $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 the 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 be a valid topology. Continuity only requires that they must have come from the topology already endowed in $X$ itself.

This begins to shine some light as to 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 work well. $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 round 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 on some $c$ in domain to $f(c)$ in 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 half-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 codomain which creates a set-theoretic boundary in the pre-image that the original domain topology never possessed. It is detected when the induced topology in the domain is found to be different and irreconcilable from 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 we might think requiring open sets to map to open sets feels like the only logical way to preserve structure.

But as we see, open images as a condition is neither necessary nor sufficient and not even justified in general. It either disallows benign smooth behaviour like local extrema or constancy but at the same time allow pathological maps to tear and scatter open sets everywhere.

Continuity works precisely under a pullback mindset. Instead of trying to propagate the structure of the domain onto the codomain, 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 in the domain or the coarsest topology in the codomain, all functions become continuous.

But this should not mean that open maps are useless in total. 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 to be structurally identical (homeomorphism).

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

Continuity prevents tearing by ensuring the structure of 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
  }
}

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 it 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.

Unevaluated Value is Function

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 replacement in replaceMin.

If we could just find a way to represent the minimum value not as a Number in JavaScript but 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 in the future. 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 xf is a function which is passed to findAndReplaceMin which replaces every element of the list a by xf. 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 evaluation of m requires xf be passed to findAndReplaceMin but findAndReplaceMin itself needs xf to be passed before m has evaluated.

Make Evidence for Faith

This seems like 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 undefined variable m without forcing the 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 in code, it would do 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 initialized.

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 would try to access the value bound to m. But note that that 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 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 can not afford to poke xf (say by doing xf()) inside findAndReplaceMin because that would just force the evaluation of m ... inside the evaluation of m ... I think you get where that would lead.

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" but with the added benefit that the definition itself can be mutually recursive 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 check how we can do exactly what we sought out to, we look at a language where delayed evaluation is built-in: Haskell

Let's see how 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 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 t x can be easily written without worrying about x 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 *) actually demands its value.

Compare this to JavaScript, where if write findAndReplace(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 the lazy evaluation (Haskell) and wrapper lambda (JavaScript) prevent automatic evaluation by runtime, we ourselves can not afford to peek into them (by pattern-matching m in Haskell or calling xf in JavaScript) before findMinAndReplace finishes execution.

If we get too impatient and lose faith, exactly the same fate awaits us in both Haskell and JavaScript: an infinite abyss of doubt till time ends!

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 can not 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 can not use recursion, which means we can not 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 explicit call for 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 define a generator function factgen and pass 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 just 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, even though fact did not call itself directly or indirectly, factgen did receive a reference to itself and used the reference in the definition of fact. 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: all declarations (including function) are not allowed.

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 was a function f defined like this:

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

and then 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 use the same behaviour but 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 higher-order 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))

evaluates 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 a 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 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 looked closely, is just h(rep(rep)) expanded. In other words, rep(rep) evaluates 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 to function h.

But there are 2 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, ie, assume we have some way through which we can delay the call to rep(rep) till just the right moment. Now, given 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) to be 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 the 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 to 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 hypothetically the declaration let fact = factgen(fact) were valid JavaScript, it would define the factorial. Alas, JavaScript refuses to accept this because 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 equality let fact = factgen(fact) describes something familiar about fact. Going back to our discussion of Y, if we think that fact is p and factgen is f, then a curious fact reveals itself: fact is nothing but the fixed point of the function factgen!

Note that what was said above is not dependent on the details of the function factorial, 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 think about why it is true, ponder over the fact that any function satisfying the above equation would behave exactly like the recursive function fact we needed to define in the first place as factgen(fact) just produces a function whose recursive calls have been delegated to fact, which is what we wanted initially.

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 as-of-yet undefined fact?

Re-enter Y

Indeed we do. Y(factgen) is nothing but the 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, every function needs to evaluate its arguments before it can be called. In technical terms, this is known as eager 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) to 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 to wrap the argument of the call h(x(x)) and replace it with 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-reference 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 h(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 computation is delayed because lambda v => rep(rep)(v) doesn't need to be reduced further until the whole expression is applied to produce some result.

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

Notice that in the last step, it doesn't matter what the argument to factgen is. No recursion is triggered and the function returned terminates if 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.