Full Workshop (2 days)
summary
A full type-level chess implementation demonstrates what Haskell’s types can enforce, and how fragile GHC’s performance can be: a naive check for “king in check” makes an 8-move game compile in 1m37s using 23GB vs 24s and 8GB without it; adding move-number details in error messages blows a 19s/4.5GB compile to ~2m and 26GB; using type-level chess model + CPS EDSL plus a ray-based check replaces huge move lists, halves memory and cuts compile-time by up to 5x on some games while revealing unpredictable GHC behavior and a few reproducible pitfalls.
AI-written summary · about
chapters (32)
- 0:00Start
- 3:29Toby Bailey
- 15:01Algorithmic Improvements
- 19:49Descriptive Error Messages
- 20:29Custom Type Errors
- 21:54Chess School Shorthand
- 22:10Creating an Optional Shorthand Syntax
- 28:21Conclusion
- 30:14Jeremy Gibbons
- 36:19Express Applications of Dynamically Typed Haskell Expressions
- 40:10Evaluate
- 40:34Heterogeneous Lists
- 42:16Encoding Variables
- 50:34Property-Based Testing
- 54:31Synthesizing Functions That Match a Set of Argument Result Pairs
- 1:08:42Automatic Function Inversion in Haskell
- 1:09:39Function Inversion
- 1:10:55Functional Patterns
- 1:11:45How Is Inverse Computation Achieved
- 1:13:15Pattern Match Compilation
- 1:30:13Limitations to the Template Haskell Implementation
- 1:34:19Is the Transformation Done on the Service Language or on Core
- 1:35:10Why Do You Use the Fm Monitor
- 1:49:14Retrofitting Linear Types to Haskell
- 1:54:32Server Response Times
- 1:54:47Latency Spikes
- 1:56:48Memory Management Can Be Expensive
- 2:00:00Bug Fix
- 2:07:02Treat Sockets as Stateful Objects
- 2:11:08The Virtues of Modularity
- 2:11:52High Performance Language Interop
- 2:12:17High Performance Language Interop
