Create lazy evaluator

Q: Create lazy evaluator

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Hard > **How to read this doc:** the entire real point of laziness — that transformations only run on values GENUINELY consumed, never eagerly on an entire (here, infinite) source — was verified directly by counting real transformation calls against a real, genuinely infinite generator: only 9, never infinite. ## 1. The problem, restated An EAGER pipeline (like a plain `array.map().filter()`) fully processes the ENTIRE source at each step before moving to the next — genuinely impossible for an infinite source, and wasteful even for a large finite one if only a few results are ultimately needed. A LAZY pipeline instead defers all transformations, only actually running them on each value AS it is pulled, one at a time, stopping the instant enough results have been produced. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Genuinely in

The problem

Problem, as an interviewer would state it: "Build a lazy evaluation pipeline supporting .map(), .filter(), and .take(n) over a real, potentially INFINITE sequence — transformations should only actually run on values that are genuinely consumed."

Examples:

Code

lazySeq(infiniteNumbers()).map(n => n*2).filter(n => n%3===0).take(3); // works, despite the infinite source

Clarifying questions expected:

Does this genuinely need to support an infinite source, or would a large-but-finite array be sufficient to demonstrate laziness?
Should chained .map()/.filter() calls compose into ONE pass over the source, or process the whole source once per operation?
Is there a real risk of an infinite loop if .take(n) is never reached (e.g., a filter that never matches)?

Code / implementation expected: Yes — real, direct proof against a genuinely infinite generator, counting real transformation calls to confirm the pipeline never eagerly processes more than strictly necessary.

js-coding
utility
algorithm

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Hard

How to read this doc: the entire real point of laziness — that transformations only run on values GENUINELY consumed, never eagerly on an entire (here, infinite) source — was verified directly by counting real transformation calls against a real, genuinely infinite generator: only 9, never infinite.

1. The problem, restated

An EAGER pipeline (like a plain array.map().filter()) fully processes the ENTIRE source at each step before moving to the next — genuinely impossible for an infinite source, and wasteful even for a large finite one if only a few results are ultimately needed. A LAZY pipeline instead defers all transformations, only actually running them on each value AS it is pulled, one at a time, stopping the instant enough results have been produced.

2. Clarif

The solution is hidden so you can try first

7 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, direct proof: a lazy map/filter/take pipeline over a genuinely infinite generator makes only 9 real map() calls, never processing the whole sequence