Extensible configurable prettyprinters
summary
Three concrete designs for an extensible configurable pretty‑printer are compared with code-level tradeoffs: a zero classes approach uses a per-type renderer value so every parametrized node must be supplied and deep nested record updates become tedious; a one class design embeds renderers in a config to reuse defaults but requires changing every occurrence of a type and complicates type-changing updates; a two classes solution uses higher‑kinded configs and monoids to update all occurrences at once but is significantly more complex and cannot render functions. Choose if you want simplicity, local overrides, or global configurable defaults.
AI-written summary · about
chapters (7)
- 0:00Start
- 0:19extensible, configurable
- 1:37Example
- 2:51Classless solution
- 5:39One-class solution
- 11:14Two-class solution
- 13:14Which is best?
related talks
17mA Pretty Expressive Printer
37mTypes that Change: The Extensible Type Design Pattern
44mPretty Parsing
01h 30mRethinking the Way We Do Templates in C++
35mRestaging Domain-Specific Languages: A Flexible Design Pattern for Rapid Development of(…)
30mLayout Polymorphism: Using static computation to allow efficient polymorphism over...
36mCool kids' way of generating code
01h 48m“Meta: Thoughts on generative C++”