Arrows as applicatives in a monad
summary
Argues that arrows are essentially applicatives with sharing and gives a concrete API: a Node type with an applicative interface whose map returns inside a Builder monad. Implements this by modeling sharing with an ST-like heap of refs, builds an incremental computation graph (Bonsai-style) that preserves sharing and compiles to a unit->unit runner. Proves an isomorphism to ordinary arrows, ships code on GitHub, and notes compile can be partial (Unbound_node) as a tradeoff.
AI-written summary · about
chapters (17)
- 0:00Arrows and use cases
- 1:06Problems with arrow interface
- 2:54Incremental computation library
- 5:02Applicatives vs arrows
- 7:33Library with applicatives
- 8:59Sharing problem with applicatives
- 10:03Mutable heaps for sharing
- 12:15Builder monad and Node type
- 13:39New API implementation
- 15:24Equivalence between the new and traditional APIs
- 16:49State threads in API
- 18:17Library trade-offs
- 19:00Summary
- 21:32Q&A: Arrow vs applicative
- 24:02Q&A: Comparisons with systems
- 26:11Q&A: Adopting new API
- 27:34Q&A: Ordering and state
related talks
36mDo it with (free?) arrows!
32mFreer Arrows and Why You Need Them in Haskell
32mApplicative: The Origin Story
46mMove Over Free Monads: Make Way for Free Applicatives!
01h 16mFunctional Composition Beyond Monads
58mMonoids, Monads, and Applicative Functors: Repeated Software Patterns
47mExtensibly Free Arrows
30mFunctional programming in Kotlin: exploring Arrow