Modularity, State & Environments

The simplest mental model for evaluation is textual substitution: to evaluate square(5) where square is defined as lambda x: x * x, imagine replacing every x in the body with 5, getting 5 * 5 = 25. This model is clean, requires no auxiliary data structures, and correctly predicts the behavior of purely functional programs with no mutation.

But the substitution model silently assumes that a name has exactly one value for all time. The moment we introduce set! (Scheme) or = reassignment (Python/C), the model collapses. Consider:

x = 1
def f(): return x
x = 2
print(f())  # prints 2, not 1

Under substitution, f would have been built with x=1 baked in. Under the real model, f looks up x at call time in a shared environment, so it sees 2. The substitution model gives the wrong answer.

The deeper problem is aliasing: two names pointing at the same mutable object. If a = [] and b = a, then a.append(1) changes what b sees too — even though we only touched a. Substitution cannot represent this at all. We need a model based on memory locations and pointers, not textual replacement.

# Substitution model would predict f() == 1; real answer is 2
x = 1
def f(): return x
x = 2
print(f())  # 2

# Aliasing — substitution can't represent this
a = []
b = a
a.append(42)
print(b)  # [42]

The environment model replaces name-as-value with name-as-binding-in-frame. A frame is a table mapping names to values (or to locations in memory). An environment is a chain of frames: each frame has a pointer to an enclosing frame, except the global frame whose enclosing pointer is null.

Evaluation rules become:

1. Lookup: to find the value of name x, search the current frame; if not found, follow the enclosing pointer and repeat; if the global frame has no binding, raise NameError.
2. Assignment (x = 5): find the frame where x is already bound (in Python, this is always the current frame unless global/nonlocal is declared) and update it.
3. Function call: create a new frame whose enclosing pointer is the frame in which the function was defined (not called!). Bind the parameters in this new frame, then evaluate the body in this new environment.

Rule 3 is the critical one. The enclosing pointer follows lexical scope (where the function was written), not dynamic scope (where it was called). This is why closures work.

The diagram in this module shows a concrete environment chain. Every Python locals() call, every JavaScript closure bug, every C stack frame — all of these are instances of exactly this structure.

# Trace the environment model manually:
x = 10           # Global frame: {x: 10}

def adder(n):     # Global frame: {x:10, adder: <fn>}
    def add(k):  # new frame E1: {n: ?}, enclosed by Global
        return n + k   # looks up n in E1, k in E1
    return add

add5 = adder(5)  # E1={n:5}, returns add (closure over E1)
print(add5(3))   # new frame E2={k:3}, enclosed by E1; n found in E1 => 8

A closure is a pair: (function-code, pointer-to-defining-environment). When you return a function from another function, you are returning this pair. The defining environment keeps all captured bindings alive, even after the outer function's frame would normally be garbage-collected.

This is the mechanism behind:

• Partial application / currying: add5 = adder(5) creates a closure that remembers n=5.
• Private state without classes: wrap mutable state in a closure; only the returned functions can touch it.
• Callbacks and event handlers: a button click handler closes over the loop variable — a classic source of bugs.

The classic JavaScript loop bug illustrates closure semantics precisely:

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 0);
}
// prints: 3 3 3  (not 0 1 2)

All three callbacks close over the same i binding (because var is function-scoped, not block-scoped). By the time they run, the loop has finished and i === 3. The fix is let i, which creates a new binding per iteration, so each closure captures a distinct frame.

In Python, closures capture variables (bindings), not values. You can mutate the captured binding with nonlocal. This is subtle: if you forget nonlocal, Python creates a new local variable instead of updating the captured one, and you get UnboundLocalError on read-before-write.

# Python closure with mutable captured state
def make_counter():
    count = 0
    def increment():
        nonlocal count   # without this: UnboundLocalError
        count += 1
        return count
    return increment

c = make_counter()
print(c(), c(), c())  # 1 2 3

d = make_counter()    # fresh environment, fresh count
print(d())            # 1  (independent of c)

Lexical scope (also called static scope): a name is resolved by looking up the chain of frames in which the function was textually defined. This is what Python, JavaScript, C, Haskell, and most modern languages use.

Dynamic scope: a name is resolved by looking up the chain of frames in which the function was called at runtime. Early Lisps (pre-Common Lisp), Emacs Lisp in legacy mode, and some shell languages use dynamic scope.

The difference is observable only when a function is called from a different lexical context than where it was defined:

;; Lexical scope (Scheme):
(define x 1)
(define (f) x)          ; f closes over the global x=1
(define (g) (define x 2) (f))  ; local x=2, but f sees global
(g)  ;=> 1

;; Dynamic scope (hypothetical):
;; (g) would call f; at call time, x=2 is in scope => result 2

Lexical scope enables referential transparency within closures and makes programs easier to reason about: you can understand f by reading its definition, without knowing who calls it. Dynamic scope is more flexible for some metaprogramming patterns (it is similar to how Python's contextlib.contextmanager or Common Lisp's let can rebind dynamic variables), but it destroys the closure abstraction.

C has neither in the full sense, because C functions are not first-class and cannot be returned. But C's block scoping and the rule that a function sees the globals at its definition site implement lexical scope for the cases C supports.

# Python is lexically scoped:
x = 'global'
def outer():
    x = 'outer'
    def inner():
        return x          # resolves to 'outer' lexically
    return inner

f = outer()
x = 'changed global'
print(f())  # 'outer' — lexical, not dynamic
            # dynamic scope would give 'changed global'

Pure functions are functions whose output depends only on their input and which produce no side effects. They are trivially parallelizable, trivially testable, and trivially cacheable. The price is that they cannot model time: a bank account balance that changes, a cache that grows, an iterator that advances.

Mutable state introduces a time dimension: the same expression evaluated at different times can return different values. This breaks two beautiful properties:

1. Referential transparency: you can no longer freely substitute equals for equals. balance evaluated before a withdrawal is not the same as balance after.
2. Confluence (Church-Rosser): the order of evaluation now matters. Two mutations to the same variable produce different results depending on which happens first.

The costs multiply in concurrent programs: two threads mutating the same state without synchronization produce data races, whose effects are undefined at the hardware level (due to cache coherence protocols and compiler reordering). This is why functional programming languages, immutable data structures, and pure functions are not just academic preferences — they are engineering tools for managing complexity.

The key insight from SICP: use assignment only when the real-world entity being modeled has genuine time-varying state (a counter, a queue, an account). If an entity is timeless (a mathematical function, a geometric shape), model it without assignment. This rule of thumb prevents enormous classes of bugs.

# Pure function — safe to call any number of times in any order
def add(a, b): return a + b

# Impure function — calling it twice gives different results
total = 0
def accumulate(x):
    global total
    total += x
    return total

print(accumulate(5))  # 5
print(accumulate(5))  # 10  -- same call, different answer

The antidote to uncontrolled mutation is encapsulation: hide mutable state behind a controlled interface. External code cannot touch the state directly; it can only interact through the methods you expose. This converts a global hazard into a local invariant.

In Python, classes provide encapsulation. But so do closures — and understanding the closure-as-object correspondence is deeply clarifying:

• Each closure invocation creates a fresh frame (the object's instance storage).
• The closure body is the method.
• Multiple closures sharing the same frame are multiple methods on the same object.

A dispatch closure explicitly demonstrates this: a single function takes a message (method name) as an argument and dispatches to the appropriate behavior. SICP's make-account is the canonical example. This shows that objects are not a primitive concept — they emerge from closures plus the environment model.

Encapsulation enforces the invariants of your data. A bank account can enforce that the balance never goes negative; a priority queue can maintain the heap property. Without encapsulation, any code anywhere can corrupt the invariant by directly mutating the underlying data.

# Closure-as-object: dispatch pattern
def make_account(initial_balance):
    balance = initial_balance         # private state

    def deposit(amount):
        nonlocal balance
        balance += amount
        return balance

    def withdraw(amount):
        nonlocal balance
        if amount > balance:
            raise ValueError('Insufficient funds')
        balance -= amount
        return balance

    def dispatch(msg):                # the 'vtable'
        if msg == 'deposit':   return deposit
        if msg == 'withdraw':  return withdraw
        if msg == 'balance':   return lambda: balance
        raise AttributeError(msg)

    return dispatch

acc = make_account(100)
acc('deposit')(50)     # 150
acc('withdraw')(30)    # 120
acc('balance')()       # 120

A namespace is a mapping from names to objects. Python, Java, C++, Haskell, and every mature language provide namespaces to prevent name collisions between independently developed code. Without namespaces, writing max = 5 in one file would silently shadow Python's built-in max, and integrating two libraries that both define a utils.parse function would be impossible.

A module is a namespace with an explicit interface (the public exports) and an implementation (the private internals). The interface is what clients can depend on; the implementation can change freely as long as the interface is preserved. This is the abstraction barrier.

Modules enforce:

1. Information hiding: implementation details that are not exported cannot be depended upon by client code, so you are free to refactor them.
2. Controlled coupling: dependencies flow only through the public interface, making the dependency graph of a large system legible and tractable.
3. Independent development: different teams can develop different modules simultaneously without stepping on each other.

In Python, every .py file is a module. import executes the module's top-level code in a fresh namespace and returns the module object. from foo import bar copies the binding bar from foo's namespace into the current namespace. __all__ declares the public interface.

In C, static functions and variables at file scope are the module system: they are invisible outside the translation unit. Header files declare the public interface. In Haskell, module Foo (publicFn) where is the declaration.

The principle of least privilege applies to modules: export only what clients need. Every additional export is a commitment you must maintain forever.

# Python module interface pattern
# --- mystack.py ---

_data = []          # private: underscore convention

def push(item):      # public
    _data.append(item)

def pop():           # public
    if not _data:
        raise IndexError('pop from empty stack')
    return _data.pop()

def peek():         # public
    return _data[-1]

# Client cannot do: mystack._data.clear()  (convention)
# But they CAN do:  import mystack; mystack.push(1)

The global frame is the root of every environment chain. Names bound there are accessible from any code that can reach the global frame, which in practice means any code in the same module (and in Python, any code that does import). This accessibility is precisely what makes global state dangerous.

Global mutable state violates encapsulation by definition: anyone can read or write it. It creates hidden dependencies — a function that reads a global variable secretly depends on whoever last wrote it. These hidden dependencies make functions hard to test in isolation (tests must set up and tear down global state), make functions unsafe to call concurrently (two threads racing on the same global), and make programs hard to reason about (understanding a function requires understanding every possible sequence of mutations to every global it touches).

The Singleton pattern in object-oriented programming is often a thinly disguised global variable with extra syntax. The same criticisms apply.

Disciplined alternatives:

• Dependency injection: pass the mutable resource (database connection, configuration, random-number generator) as an explicit parameter, so functions declare their dependencies rather than hiding them.
• Functional core, imperative shell (Gary Bernhardt): keep all business logic as pure functions; push mutation to the very edges (I/O layer, main loop). The core is testable without any setup.
• Module-level constants (not variables): global state that is truly immutable (configuration read at startup, compile-time constants) is fine.

# Anti-pattern: hidden global dependency
_db = None
def get_user(uid):
    return _db.query(uid)   # secretly depends on _db being set

# Better: explicit dependency injection
def get_user(db, uid):
    return db.query(uid)    # dependency is visible in signature

# Testing is now trivial:
class FakeDB:
    def query(self, uid): return {'id': uid, 'name': 'Test'}

result = get_user(FakeDB(), 42)  # no global state needed

Object-oriented languages (Python, Java, C++) implement the environment model with one extra twist: self (or this). When you call obj.method(args), the interpreter looks up method in obj's class hierarchy (a separate lookup chain from the lexical environment chain), creates a new frame bound to the method's code, and implicitly binds self to obj in that frame.

Python's attribute lookup follows the MRO (Method Resolution Order) chain: first the instance's __dict__, then the class's __dict__, then the base class chain in C3 linearization order. This is separate from the lexical scope chain for local variables.

The interaction between self and closures is a frequent source of confusion. In Python:

class Broken:
    def __init__(self):
        self.callbacks = [lambda: i for i in range(3)]  # classic bug

All three lambdas close over the same i in the list comprehension's scope (in Python 3, list comprehensions have their own scope, so this actually works correctly in Python 3 but not Python 2). The general principle: closures capture bindings, not values at capture time.

Class as module: in languages without an explicit module system, classes are often used purely as namespaces (a collection of static methods). This is common in Java. It is an anti-pattern relative to using a proper module system, because it invites the creation of unnecessary instances and pollutes the class hierarchy.

class Counter:
    def __init__(self, start=0):
        self._count = start  # instance __dict__

    def increment(self):
        self._count += 1    # self is bound in this frame
        return self._count

# The environment chain for increment():
# Frame: {self: <Counter obj>, ...}
#   -> enclosing: Counter class scope (for class vars)
#     -> enclosing: module global scope

a = Counter(0)
b = Counter(10)
a.increment()  # a._count = 1, b._count still 10 (separate instances)

The environment model makes the cost of function calls concrete: each call creates a new frame that must persist until the call returns. A chain of n nested calls maintains n live frames — n stack frames, each consuming memory.

A tail call is a function call that is the last action of the calling function — no work remains after the callee returns. In this case, the caller's frame is no longer needed when the callee is entered, so it can be replaced rather than stacked. This is tail-call optimization (TCO) or tail-call elimination. With TCO, a tail-recursive function runs in O(1) stack space even for arbitrarily deep recursion.

Scheme mandates TCO (R5RS §3.5). This is why SICP can write loops as tail-recursive functions without fear of stack overflow. Python deliberately does NOT implement TCO (Guido van Rossum's conscious design choice, to keep stack traces readable). C compilers perform TCO as an optimization but are not required to.

The distinction between recursive process (non-tail: builds up a chain of deferred operations, requires O(n) space) and iterative process (tail: constant space, computable by a loop) is one of the deepest insights of SICP Chapter 1. A function can look recursive while generating an iterative process:

;; Recursive process — O(n) frames:
(define (fact-recursive n)
  (if (= n 0) 1
      (* n (fact-recursive (- n 1)))))  ; deferred multiply

;; Iterative process — O(1) frames (tail call):
(define (fact-iter n acc)
  (if (= n 0) acc
      (fact-iter (- n 1) (* n acc))))   ; tail position, no deferred work

;; Scheme: tail-recursive factorial (iterative process)
(define (factorial n)
  (define (iter n acc)
    (if (= n 0)
        acc
        (iter (- n 1) (* n acc))))  ; tail call: iter is last action
  (iter n 1))

(factorial 1000000)  ; runs in O(1) stack space in Scheme

An abstraction barrier is a conceptual wall between how a data structure is used and how it is implemented. SICP formalizes this: a rational number is defined by the operations make-rat, numer, and denom — not by the fact that it is internally a pair. Any code that only uses these operations is insulated from a change in representation (e.g., switching from a pair to a reduced-fraction pair).

Abstraction barriers have four levels in SICP's hierarchy:

1. Programs that use rational numbers (arithmetic operators).
2. The rational number interface (make-rat, numer, denom).
3. The representation of pairs (cons, car, cdr).
4. The representation of integers (machine words).

Changing one level requires only modifying the code at that level, not the code above or below. This is the formal basis for information hiding and the open/closed principle: open for extension, closed for modification.

Violating the abstraction barrier — e.g., directly accessing account._balance instead of calling account.balance() — creates representation dependencies that make refactoring expensive. One of the most common sources of technical debt is code that reaches through abstraction barriers.

In Python, the convention is the single underscore _name (implementation detail, do not touch) and double underscore __name (name-mangled to prevent accidental collision in subclasses, not just convention). In Java/C++, private enforces the barrier at compile time.

# Abstraction barrier: rational number
def make_rat(n, d):
    g = gcd(abs(n), abs(d))
    return (n // g, d // g)   # implementation detail: tuple + reduction

def numer(r): return r[0]    # these three ARE the interface
def denom(r): return r[1]

def add_rat(r1, r2):
    # Uses ONLY the interface — never r1[0] directly
    return make_rat(
        numer(r1) * denom(r2) + numer(r2) * denom(r1),
        denom(r1) * denom(r2)
    )

# Now we can change make_rat to use a dict internally;
# add_rat does not need to change.

Message passing is an alternative to shared mutable state for managing concurrency and modularity. Instead of letting components reach into each other's state, each component is an actor: an autonomous entity with private state that communicates only by sending and receiving immutable messages.

The dispatch closure introduced in the encapsulation section is a micro-actor: it has private state (balance) and accepts messages ('deposit', 'withdraw'). Scaling this idea up gives the Actor model (Hewitt, 1973), which is the foundation of Erlang, Akka (Scala/Java), and to a lesser extent Python's asyncio.

In the Actor model:

• Actors have private state — no sharing, no locks.
• Actors communicate by sending messages to named addresses (mailboxes).
• Each actor processes messages sequentially (no internal concurrency), so no locks are needed within an actor.
• Actors can spawn new actors and supervise them (crash-restart trees).

The conceptual link to the environment model is direct: each actor is a closure (or object) that maintains its own environment, and message sends are function calls that execute in the receiver's environment. The key difference from ordinary closures is that actors in a concurrent system may process messages asynchronously, whereas closures are called synchronously.

Understanding message passing as a modularity technique — even in single-threaded Python — helps you design components that are loosely coupled, independently testable, and composable.

# Minimal actor-style in Python (synchronous, illustrative)
from collections import deque

class Actor:
    def __init__(self):
        self._mailbox = deque()
        self._state = {}

    def send(self, msg):
        self._mailbox.append(msg)

    def run_one(self):           # process one message
        if not self._mailbox: return
        msg = self._mailbox.popleft()
        self._handle(msg)        # private handler; no shared state

    def _handle(self, msg):
        pass  # subclasses override