Environment Diagrams Lab

Practice predicting, tracing, and building programs using Python’s environment model: frames, name lookup, and closures with local state.

0. Exit Ticket Prediction: Closure vs Global Name

**Predict the output** (without running) using the environment model.

```python
def make_adder(n):
    def adder(x):
        return x + n
    return adder

add_three = make_adder(3)

n = 100
print(add_three(10))
print(n)
```

1) What does it print?
2) In one sentence: which `n` does `adder` use, and why?

def make_adder(n):
    def adder(x):
        return x + n
    return adder

add_three = make_adder(3)

# Write your prediction as comments BEFORE running.
# I predict the two printed lines are:
# 1) ...
# 2) ...
# Why adder uses that n:
# ...

n = 100

# Uncomment to check:
# print(add_three(10))
# print(n)

`add_three` is a closure: it is code plus a parent environment pointer.

When `adder` looks up `n`, it starts in its call frame, then follows the parent pointer captured when `adder` was created.

Changing a global name later does not change what frame a closure points to.

def make_adder(n):
    def adder(x):
        return x + n
    return adder

add_three = make_adder(3)

n = 100
# Output would be:
# 13
# 100

1. Trace Call Frames: Recursive vs Loop Factorial (SICP Ex 3.9-inspired)

This exercise is about **how many frames exist over time**.

Consider these two factorial implementations:

```python
def factorial_rec(n):
    if n == 0:
        return 1
    return n * factorial_rec(n - 1)

def factorial_loop(n):
    product = 1
    k = 1
    while k <= n:
        product *= k
        k += 1
    return product
```

**Trace prompts (write answers as comments):**

A) For `factorial_rec(4)`, list each call frame created (in order), and the `n` bound in that frame.

B) For `factorial_rec(4)`, list the return values as the recursion unwinds.

C) For `factorial_loop(4)`, how many *function call frames* are created total for the computation (not counting `while` loop “iterations” as frames)? Explain briefly.

def factorial_rec(n):
    if n == 0:
        return 1
    return n * factorial_rec(n - 1)

def factorial_loop(n):
    product = 1
    k = 1
    while k <= n:
        product *= k
        k += 1
    return product

# TRACE HERE (answers as comments):
# A) factorial_rec(4) call frames (n values):
#    1) n = ...
#    2) n = ...
#    ...
#
# B) Unwinding returns:
#    factorial_rec(0) returns ...
#    factorial_rec(1) returns ...
#    factorial_rec(2) returns ...
#    factorial_rec(3) returns ...
#    factorial_rec(4) returns ...
#
# C) factorial_loop(4) frames created:
#    ... (explain)

# You may run these to sanity-check the final values:
# print(factorial_rec(4))
# print(factorial_loop(4))

Each *function call* creates a new call frame with parameter bindings.

In `factorial_rec`, the call `factorial_rec(n - 1)` must finish before multiplication can finish, so frames stack up.

In `factorial_loop`, there is only one function call to `factorial_loop`; `k` and `product` are rebound in the same frame as the loop runs.

def factorial_rec(n):
    if n == 0:
        return 1
    return n * factorial_rec(n - 1)

def factorial_loop(n):
    product = 1
    k = 1
    while k <= n:
        product *= k
        k += 1
    return product

# A) frames for factorial_rec(4): n=4,3,2,1,0
# B) returns: f(0)=1, f(1)=1, f(2)=2, f(3)=6, f(4)=24
# C) factorial_loop(4): 1 call frame total (for factorial_loop itself)

2. Build and Extend a Message-Passing Account (SICP Ex 3.11-inspired)

Implement a **message-passing** bank account using closures.

You will write `make_account(balance)` that returns a `dispatch` function.

- `dispatch('withdraw')` should return a function that takes `amount` and withdraws if possible.
- `dispatch('deposit')` should return a function that takes `amount` and deposits.

Then **extend** it:
- `dispatch('balance')` should return a *zero-argument* function that returns the current balance.

Finally, **predict** (before running) what the prints produce:

```python
acc = make_account(50)
print((acc('deposit'))(40))   # ?
print((acc('withdraw'))(60))  # ?
print((acc('balance'))())     # ?

acc2 = make_account(100)
print((acc2('withdraw'))(10)) # ?
print((acc('balance'))())     # ?
```

Your implementation should keep `acc` and `acc2` state **distinct** (two different enclosed frames).

def make_account(balance):
    """Return a dispatch function that represents a bank account.

    Messages:
      - 'withdraw' -> returns a function(amount) -> new balance or 'Insufficient funds'
      - 'deposit'  -> returns a function(amount) -> new balance
      - 'balance'  -> returns a function() -> current balance

    The local state (balance) should live in the environment frame created by
    calling make_account.
    """
    # YOUR CODE HERE
    pass


# Prediction section (write predictions BEFORE running):
# acc = make_account(50)
# print((acc('deposit'))(40))   # I predict: ...
# print((acc('withdraw'))(60))  # I predict: ...
# print((acc('balance'))())     # I predict: ...
#
# acc2 = make_account(100)
# print((acc2('withdraw'))(10)) # I predict: ...
# print((acc('balance'))())     # I predict: ...

Use `nonlocal balance` inside the inner functions that update it.

The returned `dispatch` function should *return* one of the inner functions based on the message string.

Two calls to `make_account` create two different frames, so their `balance` bindings are distinct.

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

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

    def get_balance():
        return balance

    def dispatch(msg):
        if msg == 'withdraw':
            return withdraw
        if msg == 'deposit':
            return deposit
        if msg == 'balance':
            return get_balance
        raise ValueError('Unknown message: ' + str(msg))

    return dispatch