An omitted Iterator.reduce initial value and an explicit undefined argument are different calls. Omission consumes the first source value as the accumulator and begins reducer indices at one. Supplying undefined begins with that value and calls the reducer on the first source item at index zero. This guide works the difference without hiding it behind a final sum.
This specialist guide belongs to the Websites root. It also connects to The Gold Standard of Education | Learning That Transfers into Life and the How X Works hub. The worked cases are original teaching examples; their numbers are stipulated so that the reasoning can be checked.
eduKateSG · Websites
Find your next learning step
Separate an omitted Iterator.reduce initial value from an explicitly supplied undefined accumulator across empty, one-value, multi-value and failing sources.
ROUTE 2 · CHAPTERS 4–6
Follow the decisive mechanism
Work through counters, pulls, calls and yields in their observable order.
ROUTE 3 · CHAPTERS 7–9
Change the context
Change one condition and rebuild the trace from the changed premise.
ROUTE 4 · CHAPTERS 10–12
Handle limits and evidence
Test closing, errors, shared state and evidence that separates rival explanations.
ROUTE 5 · CHAPTERS 13–15
Use and explain the result
Turn the mechanism into dependable tests, reviews and learner explanations.
Chapter contents
Build the first model · Chapters 1–3
1. Distinguish argument absence from undefined value
Follow the decisive mechanism · Chapters 4–6
Change the context · Chapters 7–9
7. Use a one-value source as a discriminator
Handle limits and evidence · Chapters 10–12
10. Trace reducer failure and closing
Use and explain the result · Chapters 13–15
CHAPTER 1 OF 15 · Build the first model
1. Distinguish argument absence from undefined value
Iterator.reduce checks whether the initialValue argument is present. Omitting it is different from supplying an argument whose value is undefined. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Reduce source 2,3 without a second argument: 2 becomes the accumulator and reducer first runs with accumulator2, value3, index1. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Call reduce(reducer, undefined). The reducer first runs with accumulator undefined, value2, index0. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. The value undefined cannot be used to infer that the argument was omitted. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
Without an initial value, reduce pulls the first source value to seed the accumulator and does not call the reducer for that seed. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Source 5,7,9: accumulator starts5; reducer calls are (5,7,1) then (12,9,2), returning21. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Add leading value1. It becomes the seed and every former value moves into a reducer call with shifted indices. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. The first source value is consumed even though it is absent from the reducer log. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
When undefined is supplied explicitly, it is the initial accumulator and every source value participates in a reducer call starting at index zero. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Reducer treats undefined as zero. Source5,7 gives calls (undefined,5,0) then (5,7,1), returning12. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Use a reducer that concatenates type labels. The first call can observe that the accumulator is actually undefined. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Do not silently replace explicit undefined with the first source value. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
The counter describes the source value passed as the reducers current value. It starts at one after an omitted initial seed and at zero after any supplied initial value. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. For source A,B, omission produces one call at index1 for B; explicit undefined produces calls at indices0 and1 for A and B. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Supply null instead. Like undefined, it is present and therefore starts calls at index zero. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Presence is determined by call arity, not by truthiness or nullishness. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
CHAPTER 5 OF 15 · Follow the decisive mechanism
5. Handle an empty source with omission
An empty iterator and no initial value cannot produce an accumulator, so reduce throws a TypeError after observing exhaustion. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Call reduce on an empty generator without a second argument and record no reducer calls plus the TypeError. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Add one source value. That value is returned directly with no reducer calls. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Do not report undefined as the reduction of an empty source when the initial value was omitted. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
CHAPTER 6 OF 15 · Follow the decisive mechanism
6. Handle an empty source with an explicit value
With a supplied initial value, an empty source returns that exact value, including undefined, without invoking the reducer. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Call reduce(reducer, undefined) on an empty source. The normal result is undefined, distinct from the omitted-argument TypeError. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Supply object marker and confirm the same object identity is returned. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. A result of undefined can be a successful reduction and must be distinguished from an uncaught error. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
One source value exposes the difference sharply: omission returns the value without a callback; a supplied initial value causes one callback at index zero. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Source10, omitted initial returns10 with zero calls. Explicit undefined invokes reducer(undefined,10,0). Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Supply initial0 and observe reducer(0,10,0), making the callback path visible without undefined handling. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. A final numeric result of10 in both cases does not prove the same mechanism ran. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
CHAPTER 8 OF 15 · Change the context
8. Keep iterator reduce separate from sparse arrays
Iterator reduction consumes produced values. Sparse-array reduce has property-presence rules before values reach its callback; converting or iterating an array can change the relevant event stream. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. An array iterator produces undefined for a hole, so its iterator reduction can call the reducer with undefined where Array.prototype.reduce would skip the absent property. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Fill the hole with an explicit undefined property and compare the array-method callback trace. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Similar method names do not erase differences between indexed-property traversal and iterator production. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
A custom iterator can expose every next call. Omission requires a seed pull followed by another pull before the first reducer call. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Log next:A, next:B, reduce:A:B:1, next:done. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. With explicit undefined, log next:A, reduce:undefined:A:0 before pulling B. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Reducer-call count alone does not include the seed pull or final done pull. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
CHAPTER 10 OF 15 · Handle limits and evidence
10. Trace reducer failure and closing
If the reducer throws, the underlying iterator is closed and the error propagates. The accumulator is not returned as a partial normal result. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Omitted seed A; reducer throws on B at index1; log source cleanup and error. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. With explicit undefined, throw on A at index0 and observe earlier closure. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. A partial accumulator is internal state unless an application deliberately catches and records it. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
CHAPTER 11 OF 15 · Handle limits and evidence
11. Separate source failure from reducer failure
A failing source step occurs before a reducer call for that step. Logs should identify whether next or the reducer caused the abrupt completion. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Source yields A as omitted seed, then next throws; reducer is never called. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Make next yield B and let reducer throw. The reducer log now includes index1 before cleanup. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Do not attribute every reduction error to the reducer function. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
CHAPTER 12 OF 15 · Handle limits and evidence
12. Track mutation and object identity
The accumulator may be an object, and the reducer can mutate or replace it. Initial-value presence still controls the first current value and counter. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Supply empty array, push source values, and return it. Calls start at index0 and final result is the supplied array identity. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Omit the initial value when the first source item is an array. That source array becomes the accumulator and later values may mutate it. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Mutation behaviour is chosen by the reducer; reduce does not clone an accumulator. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
Wrappers that forward arguments can accidentally change omission into explicit undefined. A faithful wrapper must preserve whether the second argument was supplied. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. A wrapper always calls iterator.reduce(fn, initial), where initial defaults undefined. Calling wrapper with only fn still supplies undefined downstream. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Branch on arguments.length and call reduce(fn) when the wrapper received no initial value. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Default parameter syntax does not preserve omission by itself. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
The decisive matrix uses empty and one-value sources, each with omitted and explicit undefined initial arguments. It asserts result or error, callback count and callback indices. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Cases: empty/omitted throws; empty/undefined returns undefined; one/omitted returns value with zero calls; one/undefined calls once at zero. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Add a two-value source to expose the omitted path starting at index one. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. A multi-value sum alone can hide the distinction when the reducer normalises undefined to zero. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
A complete report states call arity, seed origin, source pulls, reducer arguments, counter start, final result or error, and cleanup. Begin with the exact receiver, the underlying iterator and the operation that advances it. A familiar array analogy can help with vocabulary, but the event order must come from the iterator-helper contract being studied.
Worked case. Report that omission consumed A as seed, called reducer on B at index1 and returned the combined value after exhaustion. Write a ledger with one row for every source pull, callback call, result, yield, completion and return. This makes the counter and stopping point observable instead of leaving them hidden inside a final array or Boolean.
Trace the case from left to right. Validate the callback first, create or enter the helper, request the next source value, apply the callback with the stated counter, and only then decide whether a value is yielded or the operation stops. Do not skip a rejected value or a non-yielding event in the ledger.
Changed-context check. Changed report: explicit undefined called reducer on A at index0 and therefore executed one additional callback. Rebuild the entire trace from the changed premise. Compare the first event that differs, the values that were already consumed and the state left in the underlying iterator; those facts show whether the first explanation transfers.
Limit and misconception check. Do not describe both calls as using no initial value merely because the supplied value is undefined. State the narrow claim supported by the fixture. A result from a finite generator does not by itself establish behaviour for an infinite source, a throwing callback, a shared iterator or a consumer that stops early.
For a practical evidence check, add logging to next, return and the callback. Assert the ordered log as well as the returned value. A snapshot of final output can hide rejected values, extra pulls, early closing and counter changes, so it is weak evidence for protocol behaviour.
A useful review asks three separate questions: what did the source produce, what did the callback receive, and what did the consumer observe? Keep those answers separate. When they are collapsed into one idea of position, subtle off-by-one and cleanup errors become difficult to see.
Transfer this chapter into a short Websites explanation with four parts: the starting state, the decisive protocol step, the changed-context result and the remaining caveat. That structure gives a learner a reusable model without turning one invented fixture into a universal rule.
Continue with connected lessons
Trace sparse-array reduce accumulator selection
Trace sparse-array reduce accumulator selection. Compare iterator production with Array.prototype.reduce property-presence rules.
Separate Iterator.from identity and wrapping
Separate Iterator.from identity and wrapping. Confirm which iterator record supplies the reduction values.
Trace Iterator.take limits and closing
Trace Iterator.take limits and closing. Review source closing before composing bounded iterators with consuming operations.
Frequently asked questions
Is explicit undefined the same as omitting initialValue?
No. Argument presence controls which branch the algorithm takes.
What happens on an empty source with omission?
Iterator.reduce throws a TypeError because no accumulator can be obtained.
What happens on an empty source with explicit undefined?
It returns undefined normally without calling the reducer.
Where does the counter start?
At one when the first source value is the omitted seed, and at zero when an initial value is supplied.
Can a wrapper accidentally change omission?
Yes. Always forwarding a defaulted undefined argument supplies a value downstream.
What happens if the reducer throws?
The iterator is closed and the error propagates.
Authoritative sources and further reading
ECMAScript: Iterator.prototype.reduce. Normative argument-presence branch, seed pull, counters and reducer calls.
ECMAScript: IteratorStepValue. Source step and value acquisition used by reduction.
ECMAScript: IteratorClose. Cleanup after abrupt reducer completion.
Return to the Websites subject guide, The Gold Standard of Education, or the How X Works hub.