By name: effect-system description: "Implement effect systems to track and control side effects in programs." version: "1.0.0" tags: [effects, types, purity, popl] difficulty: intermediate languages: [haskell, purecript, koka] dependencies: [type-checker-generator, type-class-implementer]
Effect System
Effect systems track what computational effects a function may perform, enabling reasoning about purity, exceptions, I/O, and other side effects at the type level.
When to Use This Skill
- Building pure functional languages
- Reasoning about side effects
- Implementing effect handlers
- Security and sandboxing
- Optimization (pure code can be optimized more)
What This Skill Does
- Effect Annotation: Track effects in types
- Effect Checking: Verify effect constraints
- Effect Polymorphism: Generic effect handling
- Effect Row Types: Combine multiple effects
- Effect Masking: Hide effects from callers
Key Concepts
| Concept | Description |
|---|---|
| Effect | Computational side effect (IO, State, Throw) |
| Effect Set | Collection of effects |
| Effect Row | Extensible row of effects |
| Effect Polymorphism | Generic over effect sets |
| Effect Handler | Interpret effects |
| Pure | No effects |
Tips
- Start with coarse-grained effects (IO vs Pure)
- Use row polymorphism for flexibility
- Consider effect subtyping
- Effect handlers enable flexible interpretation
- Log effects for debugging
Common Use Cases
- Pure functional languages
- Effect tracking for optimization
- Sandboxing and security
- Effect-based testing
- Resource management
Related Skills
algebraic-effects- Algebraic effect handlerstype-class-implementer- Monad type classesmonad-transformer- Monad transformersinformation-flow-analyzer- Security effects
Canonical References
| Reference | Why It Matters |
|---|---|
| Lucassen & Gifford, "Polymorphic Effect Systems" (POPL 1988) | Original paper on effect systems |
| Talpin & Jouvelot, "The Type and Effect Discipline" (POPL 1992) | Effect polymorphism formalization |
| Leijen, "Koka: Programming with Row Polymorphic Effect Handlers" (2017) | Modern effect system design |
Tradeoffs and Limitations
Approach Tradeoffs
| Approach | Pros | Cons |
|---|---|---|
| Monads | Composable | Syntactic overhead |
| Effect systems | Cleaner syntax | Complex inference |
| Algebraic effects | Flexible | Runtime overhead |
When NOT to Use This Skill
- When side effects are not a concern
- Performance-critical code
- When exceptions suffice
Limitations
- Effect inference can be complex
- Higher-order effects are tricky
- Interaction with existing code
Assessment Criteria
A high-quality implementation should have:
| Criterion | What to Look For |
|---|---|
| Soundness | All effects tracked |
| Inference | Automatic effect inference |
| Polymorphism | Effect polymorphism |
| Handlers | Effect interpretation |
Quality Indicators
✅ Good: Sound, infers effects, supports polymorphism ⚠️ Warning: Manual annotations required ❌ Bad: Misses effects, no polymorphism
Research Tools & Artifacts
Effect system implementations:
| Tool | Language | What to Learn |
|---|---|---|
| Koka | Koka | Row-based effects |
| Frank | Frank | Handler calculus |
| Eff | Eff | Direct handlers |
| Multicore OCaml | OCaml | Effects in OCaml |
Research Frontiers
1. Effect Inference
- Goal: Automatic effect tracking
- Papers: "Effect Inference" (various)
Implementation Pitfalls
| Pitfall | Real Consequence | Solution |
|---|---|---|
| Effect inference | Complexity | Use bidirectional |