Closure

A function may use names that are not listed as its parameters. A closure associates that function with the surrounding bindings needed to interpret those names. The association remains useful after the function leaves its definition site; it is an execution mechanism rather than a saved picture of source text.

References: [1]

An outer function can accept a setting and return an inner function that uses it. Separate outer calls can create separate environments and specialized results. This separates choosing configuration from performing later work, without requiring every subsequent caller to pass the same setting explicitly each time.

References: [2]

Capturing a binding does not always copy its current value. Functions sharing mutable bindings may observe one another’s changes. Several callbacks can consequently read the same later value. Understanding such behavior requires identifying where bindings are created and whether the language creates a fresh binding for each loop iteration.

References: [1]

Closures can maintain counters and callback state, but retained references can also keep large objects alive. Hiding a local name is not automatically a security boundary, and retaining an environment need not preserve an entire call stack. Visibility, sharing, and lifetime are distinct aspects of the design.

References: [2]