Eager and deferred computation

This overview explains when eager and lazy paths perform the work required by a completed request. Deferring an operation can reduce unnecessary work, but it cannot erase work the requested output still needs. Suppose a caller requests the complete vector for A and B. The required output is zero zero zero one in the declared order. The comparison must end with those four bits available to the caller, regardless of how the method schedules its work. An eager path computes and stores the vector immediately. Its constructor or preparation step may therefore look expensive because it has already performed work that the caller ultimately needs. The timing boundary must make that work visible. A deferred path initially stores an operation describing the vector. This may be quick, but the four output bits have not yet been delivered. When the caller asks to read the vector, the pending work must run. Compare both paths through that materialization step. Eager construction performs aligned array work while building its representation. A lazy path defers work until the requested result needs materialization. The two timelines compare identical inputs and the same required output. Here, the four-input example requires all 16 truth outputs. The eager path performs construction and aligned array work before the request completes. The lazy path first retains a deferred structure, then materializes the full array when the complete output is requested. Both finished grids must agree at every address, including 1011 with output one. A deferred cost has moved, not vanished. If a task never requests a full array, its obligations differ from the task that does. Time preparation, request execution and extraction explicitly rather than crediting a lazy path for leaving a required step unfinished. Return to the opening two-input rule F equals A and B. This is separate from the intervening four-input contract. The complete two-input vector is zero zero zero one. If this object is never read, deferred calculation can avoid work. We will next change the caller to a point query. If the caller only needs input one zero, a point evaluator can compute zero without delivering the whole vector. This is a legitimate task change, but a point answer cannot be reported as completion of the earlier full-vector request. Repeated full reads can favor retaining materialized data after the first read. The useful boundary depends on the object's lifetime and whether later reads actually reuse it. Deferred and eager describe scheduling choices; they are not permanent speed rankings. Compare the same delivered result. Include deferred materialization, extraction, and preparation where the lifecycle requires them.