/racket-programmer

name: racket-programmer
description: Racket-specific tooling, libraries, idioms, and language-oriented programming philosophy. Use when working with Racket code. Emphasizes LOP, contracts, macros, and design methodology.

Racket Programmer

Expert-level Racket programming skill focused on judgment frameworks, language-oriented programming philosophy, and production practices.

**Related skills:**

• `software-engineer` - Core programming philosophy and SICP principles that underpin Racket's design
• `functional-programmer` - FP patterns and thinking (Racket is fundamentally functional)
• `test-driven-development` - General testing philosophy; this skill covers RackUnit specifics

Version Targeting

**Always target the latest stable Racket version** unless explicitly working on a codebase with version constraints.

• Latest stable: Racket 8.18 (as of August 2025)
• Download: https://download.racket-lang.org/
• Version history: https://github.com/racket/racket/releases
• For historical context: https://en.wikipedia.org/wiki/Racket_(programming_language)#History

**Racket CS (Chez Scheme-based) is the default implementation since 8.0.** Strong backward compatibility commitment means minimal version fragmentation.

**For owned codebases:** Aggressive upgrade philosophy. Use latest features and libraries.

**For third-party codebases:** Respect existing version targets and conventions. When contributing to open source, follow the project's existing standards. Don't introduce modern features to projects targeting older versions. Propose improvements through proper channels (issues, governance).

<language_oriented_programming>

Language-Oriented Programming: Racket's Core Philosophy

**Central Insight**: Racket's defining characteristic is building solutions as languages, not just libraries. Every problem is approached by asking "what's the right notation?" before "what's the implementation?"

This is not a feature of Racket—it IS Racket's design philosophy. Understanding this distinction separates using Racket from merely writing Scheme with extra features.

From "The Racket Manifesto" (Felleisen et al., SNAPL 2015)

**"A programmable programming language."** Racket is designed to let programmers create languages tailored to specific problem domains. The language grows through the creation of new languages, not just new libraries.

**Key principle**: "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." —Gerald Weinberg

The right notation eliminates entire classes of errors at compile time. Language design is not an esoteric activity—it's the solution to the problem of making correct code easy to write and incorrect code hard to write.

Decision Framework: #lang vs Library vs Macro

Does solution need non-S-expression syntax?
  → Reader extension needed → #lang

Does solution benefit from compile-time validation of entire program?
  → Custom #%module-begin → #lang

Just adding new operations/abstractions?
  → Macros + provide → library

Need IDE integration (syntax coloring, specialized checks)?
  → #lang with language info

Notation precision outweighs learning curve?
  → #lang

When Language-Oriented Design Excels

1. **Novice interfaces** - Create simpler notations for less-skilled programmers (HtDP teaching languages) 2. **Simplified notation** - Regular expressions, configuration DSLs where domain notation is clearer 3. **Existing notation** - BNF grammars (brag package), standard formats that users already know 4. **Intermediate compilation targets** - JSON with embedded computation, specialized formats 5. **Configuration-heavy domains** - Test specifications, API definitions where structure matters

**Essential Reading:**

• Beautiful Racket: https://beautifulracket.com/ (comprehensive LOP tutorial—**read this**)
• "Why Language-Oriented Programming?": https://beautifulracket.com/appendix/why-lop-why-racket.html
• "Creating Languages in Racket" (Flatt): https://queue.acm.org/detail.cfm?id=2068896

**Trade-offs:**

• ✅ Perfect notation-to-problem fit, early error detection via compiler, domain expert usability
• ❌ Learning curve, infrastructure maintenance overhead, tooling support complexity
• **Decision heuristic**: Use when minimum notation with maximum precision is critical

Language Towers: Composable Language Abstractions

**Pattern**: Build languages on languages, creating towers where each layer provides abstractions for the next. Unlike traditional macros that compete, Racket macros cooperate through shared compile-time information.

**Key Paper**: "Macros that Work Together" (Flatt et al., 2012)

Racket achieves this through:

• **Partial expansion**: Macros can expand sub-forms partially, inspect results, continue with additional context
• **Definition contexts**: Macros cooperate by maintaining lexical scope through hygiene
• **Phase separation**: Compile-time vs runtime code cleanly separated

**Example**: Racket's class system is implemented as macros over struct, which is itself a macro. Each layer maintains proper scoping and composition.

This is a fundamental difference from other Lisp macro systems where macros often interfere with each other. </language_oriented_programming>

<contracts_and_blame>

Code as Contracts: Module Boundaries and Blame

**Core Pattern**: Modules are units of abstraction AND units of blame for contracts. Design module boundaries intentionally with this in mind.

Contracts in Racket are not optional documentation—they are executable specifications that assign blame when violated. This is fundamentally different from assertions (which blame the entire program) or types (which reject programs statically).

Contract-Out: The Standard Pattern

(provide
  (contract-out
    [my-function (→ number? (>/c 0) boolean?)]
    [my-struct (struct/c point [real? real?])]
    [complex-fn (→i ([x number?]
                      [