Extensible Effects: A Leaner Cake for Purely Functional Code
summary
Compares free-monad algebras to tagless‑final and shows concrete rewrites: a map-backed KV storage and an SVG renderer/compiler move from free + WriterT (lots of allocations, linear pattern‑match interpreters, boilerplate) to trait-based final encoding (no allocated algebra trees, better type inference, fewer allocations). Demonstrates adding a WriterT logging of removed keys by composing interpreters instead of transforming program data, and explains using extensible‑effects (Typelevel F / eff style stacks) to touch existing writer effects without adding layers. Claims: final reduces GC pressure and runtime pattern‑match cost; ext effects preserve flexibility and stack safety.
AI-written summary · about
chapters (25)
- 0:00Introduction
- 0:57MapStorage
- 1:57SVGRenderer
- 4:52Initially Tagless
- 6:44Products
- 7:03The Free Approach
- 7:57Program Augmentation
- 9:33Free Structures
- 11:06Example
- 14:12Program Transformation
- 15:34Free Structure Algebra
- 18:10Services
- 18:50Programs
- 19:29Nodes
- 20:22Storage
- 22:08Program transformations
- 23:08Program example
- 23:29Stack safety
- 24:13Bring free back
- 24:49Mona transformers
- 25:27Why extensible effects
- 25:55TypeLevelF
- 27:16Final remarks
- 27:34Questions
- 29:10F for performance
related talks
01h 06mThe Evolution of Effects
50mFunctional Programming with Effects
43mSurviving a world overflowing with effects
43mFunctional Programming with Effects
28mA Series of Unfortunate Effects
44mEffects, Algebraically yours ..
43mFree monad or tagless final? How not to commit to a monad too early
01h 14mBeyond Free Monads