The Future Is Comonadic!

The Future Is Comonadic!

My talk about comonadic UIs, from May Day-Convoluted Weekend.

Cbed6f201f9a0e735e5660d118c6662d?s=128

Phil Freeman

May 27, 2018
Tweet

Transcript

  1. Phil Freeman COMONADIC! The e Is coday.today

  2. Hello • Hello, I’m Phil • I write Haskell and

    PureScript at Lumi • I like building user interface libraries in PureScript: ◦ React-Basic ◦ Thermite ◦ SDOM ◦ Behaviors ◦ Purview ◦ React-Explore • I also like to study category theory
  3. Agenda • An intuition for comonads • How can we

    specify user interfaces? • How can we talk about specifying user interfaces? • Some other interesting ideas
  4. Monads Mon Image: NASA

  5. None
  6. Monads class Functor m ⇒ Monad m where return ∷

    a → m a join ∷ m (m a) → m a (>>=) ∷ m a → (a → m b) → m b (>=>) :: Monad m ⇒ (a → m b) → (b → m c) → a → m c (f >=> g) a = f a >>= g f >=> return = f return >=> f = f f >=> (g >=> h) = (f >=> g) >=> h
  7. Comonads class Functor w ⇒ Comonad w where extract ∷

    w a → a duplicate ∷ w a → w (w a) (=>>) ∷ w a → (w a → b) → w b (=>=) :: Comonad m ⇒ (w a → b) → (w b → c) → w a → c (f =>= g) w = g (w =>> f) f =>= extract = f extract =>= f = f f =>= (g =>= h) = (f =>= g) =>= h
  8. Examples?

  9. The Store Comonad data Store s a = Store s

    (s → a) instance Comonad (Store s) where extract (Store here go) = go here duplicate (Store here go) = Store here $ \there → Store there go
  10. The Traced Comonad data Traced w a = Traced (w

    → a) instance Monoid w ⇒ Comonad (Traced w) where extract (Traced f) = f mempty duplicate (Traced f) = Traced $ \w → Traced (f . (w ◇))
  11. Intuition?

  12. None
  13. More Reading • Cofree meets Free http://blog.sigfpe.com/2014/05/cofree-meets-free.html • Comonads in

    Everyday Life https://fmapfixreturn.wordpress.com/2008/07/09/comonads-in-everyday-life/
  14. Declarative UIs Trends in UIs: • No more direct manipulation

    • One-way data flow • Describe what the UI state should be, not how to reach it.
  15. Virtual DOM The virtual DOM API in 4 lines: data

    VDOM e data Patch diff ∷ VDOM e → VDOM e → Patch apply ∷ Patch → IO Unit (e f Eve s )
  16. Components We can build components: data Component model = Component

    { initialState ∷ model , render ∷ model → VDOM model }
  17. E.g. Counter counter ∷ Component Int counter updateState = Component

    { initialState: 0 , render = \value → button [onClick \_ → value + 1] [text ("Current value = " ⧺ show value)] }
  18. A Comonad Appears Hey, that looks like Store! type Component

    model = Store model (VDOM model) What do the Comonad functions do? extract ∷ Component model → VDOM model duplicate ∷ Component model → Store model Component
  19. The Future is Comonadic extract ∷ Component model → VDOM

    model extract renders the component’s current state duplicate ∷ Component model → Store model (Component model) duplicate captures the possible future states of the component
  20. Exploring the Future How can we explore the future? future

    ∷ Store model (Component model) We need a function explore ∷ Store model Component → Component model Image: xkcd.com
  21. Exploring the Future To usefully implement explore ∷ Store model

    Component → Component model we can • read the current state • move to a new state Which can be packaged up using the State monad
  22. Exploring the Future explore ∷ State model () → Store

    model Component → Component model explore state (Store here go) = go there where (_, there) = runState state here
  23. Components using State data Component model = Component { initialState

    ∷ model , render ∷ model → VDOM (State model ()) }
  24. Counter using State counter ∷ Component Int counter updateState =

    Component { initialState: 0 , render = \value → button [onClick \_ → modify (\n → n + 1)] [text ("Current value = " ⧺ show value)] }
  25. Let’s Summarize • A component is described by Store model

    (VDOM (State model ())) • We can render a component using extract • We can observe possible future states of a component using duplicate
  26. Let’s Generalize! • A component is described by w (VDOM

    (m ())) • We can render a component using extract • We can observe possible future states of a component using duplicate (Laz va ed!)
  27. Pairings We require the existence of a function explore ∷

    m () → w a → a We can use the more general concept of pairing ∷ m (a → b) → w a → b
  28. Pairings State s Writer w Reader e Free f Free

    ((,) i) Store s (React) Traced w (Incremental) Env e Cofree g (*) (Halogen) Cofree ((→) i) (Redux, Elm) * when f pairs with g pairs with
  29. Pairings For Free We get a (law-abiding!) monad with a

    pairing for free: (http://comonad.com/reader/2011/monads-from-comonads/) data Co w a = Co (∀ r. w (a → r) → r) instance Comonad w ⇒ Monad (Co w) explore :: Co w (a → b) → w a → b
  30. Let’s Summarize • A component is described by w (VDOM

    (Co w ())) • We can select the next future state using Co w () This is implemented in purescript-react-explore. type Handler w = Co w () type Component w = w (VDOM (Handler w)))
  31. So What? • We’ve unified several common approaches to UIs

    under one abstraction • We have control over component state transitions • We now have a language for studying the approaches themselves ◦ E.g. comonad morphisms correspond to interpreters ◦ E.g. every comonadic UI can be interpreted using Store (React) • We can generalize this approach to comonads in other categories • We can use this intuition to find new comonads
  32. Further Reading...

  33. Combining Components

  34. Day Convolution Day (1970) defines the following convolution product of

    functors: For example: data Day f g a = forall x. Day (f (x → a)) (g x) Day ((→) w) ((→) w’) a ~ exists x. (w → x → a, w’ → x) ~ w → w’ → a ~ (w, w’) → a
  35. Day Convolution Theorem Day f g is a comonad whenever

    f and g are both comonads. In fact, Day makes the comonad category into a (closed) symmetric monoidal category. TO : fi n u t e y ex n is
  36. Day Convolution Day (Store s) w Day (Traced w’) w

    Day (Env e) w StoreT s w TracedT w’ w EnvT e w ≅
  37. Symmetric Monoidal Categories A symmetric monoidal category ( , ⨂,

    I) is defined by a bifunctor ⨂ : ⨉ → with unit I (*) which is • Associative (*) • Symmetric (*) * up to isomorphism
  38. Closed Symmetric Monoidal Categories A closed symmetric monoidal category has

    right adjoints for each tensoring functor A ⨂ - : → A ⇒ - : →
  39. Closed Symmetric Monoidal Categories We can use linear lambda calculus,

    the internal language of closed symmetric monoidal categories to talk about Day convolution and component composition.
  40. Day is Closed The internal Hom is given by Notice

    that: data Hom f g a = Hom (∀ r. f (x → r) -> g r) Hom f Identity a ~ ∀ r. f (x → r) -> r ~ Co f a
  41. move ∷ ((f ⇒ 1) ⇒ (g ⇒ 1) ⇒

    (f ⨂ g ⇒ 1)) () move = ⟦ linear | \f† g† pair let (f, g) = pair () = f† f in g† g ⟧ Monads Annihilate Comonads To change application state, we need E.g. (f ⇒ 1) ()
  42. Comonad Optics We can form optics for comonads just like

    lenses for types: type Optic s t a b = s ↝ a ⨂ (b ⇒ t) day1 ∷ Optic (a ⨂ c) (b ⨂ c) a b day2 ∷ Optic (c ⨂ a) (c ⨂ a) a b store1 ∷ Optic (StoreT s a) (StoreT s b) a b store2 ∷ Optic (StoreT s a) (StoreT s’ b) (Store s) (Store s’) (Lo k s ik L !)
  43. Iterated Day Convolution Day is our internal product type Let’s

    form an internal record type! See purescript-smash (also an implementation of extensible coeffects) data Smash (r ∷ # (Type -> Type)) a
  44. Bits and Pieces • Comonads are closed under certain equalizers

    • There is a Sum construction for modeling UIs with multiple optional states ◦ Can also be used to construct UIs for lists
  45. Questions?