A Wick Is a Lazy Generator

A wick doesn’t push wax into the flame. I spent the first evening of candle making assuming it did — that the cotton somehow fed fuel upward like a tiny conveyor belt. It doesn’t. The flame melts a shallow pool at the base, and capillary action draws liquid wax up the fibres only as fast as the flame burns it off. Nothing moves until the flame asks for it. Pinch the flame out and the pull stops mid-fibre.

That’s a pull system, and programmers have a name for the same arrangement: demand-driven, or lazy, evaluation. A value isn’t produced until a consumer reaches for it.

Here’s the wick as a generator in C, where a static local stands in for the coroutine the language won’t give us:

#include <stdio.h>

double wick(void) {              /* capillary pump: one draw per call */
    static double reservoir = 4.0;
    return reservoir > 0.0 ? (reservoir -= 1.0, 1.0) : 0.0;
}

int main(void) {
    for (int i = 0; i < 3; i++)
        printf("flame draws %.1f unit of wax\n", wick());
    return 0;
}

The reservoir sits untouched between calls. Three burns, three draws, and the fourth unit never gets computed.

Ruby says the same thing with an Enumerator, which suspends its block until you call next:

wax = Enumerator.new do |y|
  drop = 1.0
  loop { y << drop }   # willing to supply forever...
 end

3.times { puts "flame draws #{wax.next} unit of wax" }

The loop reads as infinite, but it runs exactly three times — once per pull.

The failure mode maps over too. Fit an oversize wick and it draws faster than the flame can consume; the pool floods, the flame gutters and throws smoke. That’s eager evaluation with nowhere to put the results. Wick sizing turns out to be rate-matching your supply to the consumer’s appetite — a scheduling problem I did not expect to meet inside a mason jar.