Week 3: Side Effects of Procedures

BSCS1001 — IIT Madras BS Degree Prerequisite: Topic 05 (Procedures & Parameters) Cross-links: BSCS1002-Python (Week 5 — Function Side Effects), BSCS2002-PDSA (Week 3 — Purity)

1. Motivation: What Happens to the Data?

Real-world analogy: You lend a friend a book. You expect it back in the same condition (no side effects). But if your friend is a bookbinder who repairs torn pages, you might want them to fix things (desirable side effect). The key is knowing what to expect.

2. What is a Side Effect?

Examples of Side Effects

The Key Question

Does the caller care if the data is modified?

3. The Card Deck: A Concrete Example

sql
while (Pile 1 has more cards) {
    Pick a card X from Pile 1
    Move X to Pile 2
    // Process X
}

What Happens to the Deck?

Does the Reversal Matter?

4. Desirable Side Effects

Example: Sorting the Deck

pseudo
Procedure SortDeck() {
    // Rearrange cards in descending order of Total marks
    // The side effect (rearranging) is the whole point!
}

Example: Deleting a Key from a Dictionary

pseudo
Procedure DeleteKey(d, k) {
    myd = {}
    foreach key in keys(d) {
        if (k ≠ key) {
            myd[key] = d[key]
        }
    }
    d = myd    // Side effect: d is modified
End DeleteKey

Example: Adding a New Student

pseudo
Procedure AddStudent(newMark) {
    marksList = marksList ++ [newMark]   // Side effect: list grows
    aValue = -1                          // Side effect: cache invalidated
End AddStudent

When Side Effects Are Desirable

5. Undesirable Side Effects

Example: Pronoun Resolution

pseudo
// This procedure has an UNDESIRABLE side effect:
Procedure FindOverlap(11, 12) {
    overlap = []
    foreach x in 11 {
        foreach y in 12 {
            if (x == y) {
                overlap = overlap ++ [x]
            }
        }
    }
    // Side effect: 12 has been consumed/restructured!
    return(overlap)
End FindOverlap

Why Undesirable Side Effects Are Dangerous

6. Interface vs Implementation

The Interface

The Implementation

Why Separate Interface from Implementation?

Example

sql
// Interface: Find maximum of a field
// Parameters: fld - the field to check
// Returns: the maximum value found
// Side effect: Cards are moved from Pile 1 to Pile 2
Procedure MaxMarks(fld) {
    // Implementation can be anything that satisfies the interface
    Max = 0
    while (Pile 1 has more cards) {
        Pick a card X from Pile 1
        Move X to Pile 2
        if (X.fld > Max) {
            Max = X.fld
        }
    }
    return(Max)
End MaxMarks

7. The Procedure Contract

Contract Examples

pseudo
Functionality:
  - Parameters: gen (gender), fld (field name)
  - Returns: Sum of fld for students of gender gen
Data Integrity:
  - Side effect: Cards are moved to Pile 2 (doesn't affect computation)
  - Predictable: Yes — deck will be reversed

sql
Functionality:
  - Parameters: d (dictionary), k (key to delete)
  - Returns: nothing (void)
Data Integrity:
  - Side effect: Key k is removed from dictionary d
  - Predictable: Yes — exactly one key removed

pseudo
Functionality:
  - Parameters: nounList, pronounList (both sorted)
  - Returns: Matched pairs
Data Integrity:
  - Side effect: NONE — input lists must remain sorted
  - Guarantee: Input lists are NOT modified

8. Side Effects with Collections

Lists and Side Effects

pseudo
Procedure AddItem(myList, item) {
    myList = myList ++ [item]    // Side effect: modifies the list
End AddItem

Avoiding Side Effects with Lists

pseudo
Procedure AddItemSafe(myList, item) {
    newList = myList              // Make a copy
    newList = newList ++ [item]   // Modify the copy
    return(newList)               // Return the modified copy
End AddItemSafe

The Side-Effect-Free Pattern

sql
// WITH side effect (procedure modifies input)
Procedure DeleteKey(d, k) {
    foreach key in keys(d) {
        if (k == key) {
            remove key from d     // d is changed!
        }
    }
}
// WITHOUT side effect (procedure returns new dictionary)
Procedure DeleteKey2(d, k) {
    myd = {}
    foreach key in keys(d) {
        if (k ≠ key) {
            myd[key] = d[key]    // Building new dictionary
        }
    }
    return(myd)                  // Original d is unchanged
End DeleteKey2
// Caller must reassign:
myd = DeleteKey2(myd, k)         // Caller explicitly updates reference

9. Managing Side Effects

Best Practices

Decision Flowchart

10. Comparison Table

Pure vs Impure Procedures

Desirable vs Undesirable Side Effects

11. Practice Questions

Basic Questions

Show Answer

A side effect occurs when a procedure modifies some data during its computation, beyond just returning a value. Examples: reordering cards, modifying a list, changing a dictionary. Q2. Give one example of a desirable side effect and one example of an undesirable side effect. Show Answer

• Desirable: Sorting a deck of cards (the rearrangement IS the goal)
• Undesirable: A procedure that finds max marks but accidentally reverses the deck, destroying the original order that another procedure relied on. Q3. What is the difference between a procedure's interface and its implementation? Show Answer
• Interface — the contract: what parameters, what return value, what side effects
• Implementation — the actual code inside the procedure

You can change the implementation without affecting the caller, as long as the interface stays the same. Q4. In the standard iteration pattern, what side effect occurs to the card deck? Show Answer

Cards are moved from Pile 1 to Pile 2. Since cards are picked from the top of Pile 1 and placed on top of Pile 2, the deck ends up in reverse order compared to the original.

Intermediate Questions

pseudo
Procedure DoubleList(L) {
    i = 0
    while (i < length(L)) {
        L[i] = L[i] * 2
        i = i + 1
    }
End DoubleList

Show Answer

Side effect: The input list L is modified — each element is doubled.

Is it desirable? That depends on the contract. If the procedure is called "DoubleList" and the caller expects L to be modified, then YES. But if the caller expects a new list to be returned (and L untouched), they would be surprised.

Better design: Either:

1. Document: "Side effect: modifies L in place"
2. Or make it pure: create and return a new list Q6. Rewrite DeleteKey so it has NO side effects (pure function). Show Answer

pseudo
Procedure DeleteKeyPure(d, k) {
    newDict = {}
    foreach key in keys(d) {
        if (key ≠ k) {
            newDict[key] = d[key]
        }
    }
    return(newDict)
End DeleteKeyPure

// Usage: myDict = DeleteKeyPure(myDict, "someKey")
// Original myDict is unchanged; we reassign the result

Show Answer

1. Work on a copy: Inside the procedure, copy the input data and work on the copy. Return the modified copy instead of changing the original.
2. Document it: If the side effect cannot be avoided, clearly document it in the procedure's contract so the caller knows what to expect.

Show Answer

The deck is in whatever state procedure A left it (sorted, if B doesn't rearrange). But the standard iteration pattern in B moves cards from Pile 1 to Pile 2, which reverses them. If A sorted descending, after B the cards are in ascending order (since Pile 2 is reversed from Pile 1).

This is a classic example of unexpected interaction between side effects.

Advanced Questions

Show Answer

pseudo
// Contract for FindCommonElements
// Parameters:
//   list1 - sorted (ascending) list of integers
//   list2 - sorted (ascending) list of integers
// Returns:
//   A new list containing elements present in both list1 and list2
// Side effects:
//   NONE - input lists are NOT modified
//   (Internal implementation uses first() and rest() which modifies
//    the list copy, not the original)

Procedure FindCommonElements(list1, list2) {
    common = []
    // Implementation that avoids side effects...
    return(common)
End FindCommonElements

pseudo
1. Create list L = [3, 1, 4, 1, 5]
2. Call Sort(L)          // Sorts L ascending
3. Call Reverse(L)       // Reverses L
4. Call Max(L)           // Finds max

Show Answer

Final L = [5, 4, 3, 1, 1] (reversed from original) Q11. Why is it important to document side effects in a procedure's contract? Show Answer

1. Caller awareness — The caller needs to know if their data will be modified
2. Correctness — The caller can account for side effects in subsequent code
3. Debugging — If something goes wrong, documented side effects help trace the issue
4. Maintainability — Future changes to the procedure must preserve the contract
5. Reusability — Other programmers can use the procedure correctly

Without documentation, callers might assume their data is safe when it isn't. Q12. In the classroom dataset example (Week 10), addStudent resets aValue to -1 as a side effect. Explain why this side effect is both desirable and potentially dangerous in a concurrent context. Show Answer

Desirable because: When a new student is added, the cached average (aValue) becomes stale. Resetting it to -1 forces average() to recompute the correct value. This is a necessary side effect for correctness.

Dangerous because (concurrent context): If average() is running at the same time as addStudent(), there's a race condition. The average might read aValue while addStudent is changing it, getting an incorrect result. Or average might compute using the marksList while addStudent is appending to it — leading to corrupted data.

This is why concurrent access needs atomicity (non-concurrent access to shared state).

📚 Cross-References

Next Topic: 07 — Nested Iterations

Quiz Tip: Side effect questions ask you to predict what state data is in after a procedure. Always trace the deck/card movements! Join Discord PreviousProcedures & ParametersNextNested Iterations