HTDP Study Blog

Source: Dev.to

This blog is a comprehensive study guide distilled from many past exams (2019–2024) and lecture rules in HTDP / Racket. It focuses on evaluation, function design, data‑driven templates, recursion, abstraction, local/closure, and common exam traps.

Author’s note
This blog was summarized from everyday notes and mistake summaries while revising for exams. Its sole purpose is to help write clear, readable, and collaboration‑friendly code, and to understand the underlying execution model of Racket programs. It does not cover the three algorithm‑focused chapters (e.g., graphs, accumulators, and search). For those, the most important advice is: go through past papers by yourself. Separate blog posts will be written later to specifically cover the algorithmic content in HTDP.

---

Evaluation Questions (Step‑by‑Step Reduction)

Core Rules

• Substitute all parameters at once.
• Substitute constants defined by define one by one, in order.
• For cond, reduce the condition first, then evaluate the chosen branch.
• For or, the first true value stops evaluation.
• Always run the program to confirm the final value.

---

Function Debugging Questions

Common Fixes

• Predicate functions must end with ?.

Frequent Bugs

• Swapped coordinates in selectors.

---

HTDD (How to Design Data)

Rules

• The last condition in cond should use else.

---

HTDW (World Programs)

Key Events

• Handle key events using a cond on the key value, with a final else case that returns the unchanged world.

Tips

• The render function must be defined before big-bang.

---

Reference and Recursion Questions

Self vs. Mutual Reference

• Self‑recursive: a function calls itself.

Trust Natural Recursion

• Once the first element is correct, trust the rest.

Empty Base Cases (VERY IMPORTANT)

• The sum of an empty list returns 0.

---

Abstraction and Higher‑Order Functions

Choosing the Right Abstract Function

• Use map or filter when the goal is to produce a list.
• Use foldr or foldl when the goal is to aggregate values.
• Use build-list when generating a list based on indices.

Function Signatures

• map : (X → Y) → (Listof X) → (Listof Y)
• filter : (X → Boolean) → (Listof X) → (Listof X)
• foldr : (X Y → Y) → Y → (Listof X) → Y
• build-list : Natural → (Natural → X) → (Listof X)

Common Error

• Do not call a function when passing it as an argument.

---

Local, Closure, and Lifting

Closure Definition

A function is a closure if:

1. It is a function.
2. It uses variables not listed in its parameters.
3. Those variables come from an outer scope.

Evaluation Cost

• Definitions outside loops are evaluated once.
• Definitions inside loops are evaluated on every iteration.

---

Genrec (Generative Recursion)

Must Include

• A base case.
• A reduction step.
• A termination argument.

Common Mistake

• A wrong base case leads to incorrect images or values.

---

Well‑Formed Data Definitions

• Not well‑formed: (examples of malformed definitions)
• Well‑formed: (examples of correct definitions)

---

Helper Functions — When Are They Needed?

Use a helper function when:

• Referencing non‑primitive nested data.
• Performing two‑phase processing.
• Switching knowledge domains.
• Handling arbitrary‑sized data such as lists or trees.

---

Parameters vs. Arguments vs. Operands

• Parameter: a name in a function definition.
• Argument: the actual value supplied at a call site.
• Operand: a value on which an operator works (e.g., the two numbers in +).

---

Exam Survival Checklist

• Follow the template strictly.

---

Final Advice

Design correctly, then trust recursion. HTDP exams reward discipline, templates, and precision—not clever hacks. As a beginner, I felt very rewarded by learning these basic design principles and extending them in future programming as a behaved and cooperative programmer.