A monad for reactive programming Part 2

Some time has passed since I published the first part of this tutorial. The time has been spent in achieving a deeper understanding of events and event processing. In this second part I solve the problems of the simple approach depicted at the end of the part 1.

The motivating example to solve is the same, a console application with a basic event scheduler, a monadic computation that has some statements which wait for different kinds of events. You can run the two examples here in the tutorial.

This tutorial also can be considered as the description of an event sourcing mechanism without inversion of control. A event sourcing application is basically a set of event handlers for each type of event with a central state. A functional reactive mechanism is a single event handler with event preprocessing on top. while a monadic reactive mechanism like this is a monadic computation that automatically generates a cascade of event handlers.

Besides monadic reactive, I will demonstrate more classical functional reactive behaviour using applicative combinators, and how to mix monadic, reactive and alternative to mimic the creation of new signals with thresholds etc.

The tutorial and running examples are in the School of Haskell

Browser programming: React.js as a solution for a problem that Haskell can solve in better ways

This is what i wrote in this Reddit thread.

IMHO virtual-dom as well as React tries to solve a problem specific of javascript: the lack of a intuitive, composable way to update the HTML-DOM tree. So it creates a composable intermediary, a lineal virtual-dom. Basically, it is string concatenation. When changed, the intermediary lineal description is rendered. But the rewrites and re-rendering are expensive, so they need to update only what is changed.

That problem disappears when there is a way to write directly the HTML-DOM in a composable way, using a monoid or a monad. Then, to rewrite any branch, just go to the element and update it also in a composable way. That is what I want to detail below:

Basically, both virtual-dom and react use intermediary lineal images of the dom just to be able to do this:

div [atribute "width" 100] $ ("hello") <> div [attribute "height" 200] "whathever"

Since strings are composable in javascript as well as in any language. But trees are not.

That composable syntax is impossible in javascript with the HTML DOM directly.

But Haskell has a lot more tricks. It is possible to compose functions as monoids. these functions may be builders of DOM elements. these builder functions create dom elements, attributes etc using DOM primitives inside.

That is what ahem.... what my perch library does.

https://github.com/agocorona/haste-perch

It updates directly the HTML-DOM in a composable way as if they were blaze-html elements IN the browser:

div $ do

   div ! atr "width" "100"  $ "hello" 

   div ! atr "height" 200 $ "whathever"

and so on. div here is a builder function. it can be composed this way, monadically or with a monoid syntax. Both are equivalent, like in the case of the blaze-html library. but while blaze-html concatenate strings, perch concatenate builder functions that create trees. In the above example, in creates a div node with two more divs inside.

Do you want to update an element? modify it directly. Since it does not update an intermediary description, there is no need to detect differences in the intermediate description to avoid to render again the whole description. It simply does it in the DOM.

forElems ".classtochange" $ this ! width "300" ! atr "class" "changed"

The above expression is similar to a jquery modification. it is applied for all the elements that match.

in lineal descriptions like the ones of virtual-dom or react each element is not directly addressable. To address the elements is as expensive as to sequentially rewrite the description with a new one. The need to detect differences is then a consequence of a lineal description. And the lineal description a consequence of the need of composability.

But a set of monoidal combinators of functions that update the DOM are composable . And it is pure Haskell, no need to use Javascript libraries.

Usage in Reactive Frameworks

I have to say that the virtual-DOM-React approach is ideal for functional reactive frameworks like Elm and others, since them manage the page as a whole. Every signal may change the whole page. I´m not an expert and my knowledge of this is far from accurate, but it seems to me that there are no event scopes, since the events feed a single entry point that re-render the whole page, as far as I know. Or alternatively they modify placeholders in a static template. Without React , Elm and all the functional reactive frameworks were limited to the second option. With it, they can perform more dynamic DOM effects. without React, it was hard to create a responsive TODO application in a functional reactive framework.

Monadic functional reactive may be more promising, since the events can be catched and managed locally (and the DOM updates are local too) they don't affect the whole computation and the re-rendering of the entire page. As the paper is the Google search says: "In other (non monadic) FRP approaches, either the entire FRP expression is re-evaluated on each external stimulus, or impure techniques are used to prevent redundant re-computations". That is the problem that Monadic Reactive solves.

I don´t know how to to slip here hplayground which is a monadic functional reactive framework for Browser applications. For this framework, Perch is perfect. But also is fine as such, with event handlers managed by perch itself.

Haskell running in the #cordovajp phonegap framework for hybrid smartphone applications.

#Haskell running in the #cordovajp phonegap framework for hybrid smartphone applications. Details soon #javascript pic.twitter.com/toKsSKnZ8r
— Alberto G. Corona (@AGoCorona) November 13, 2014

The source code and the instructions are here





The code has been put in another place avoid the disastrous and ever embarrassing formatting nightmares of Blogger.com, that does whatever it wants with my posts, that convert copying and pasting into a horror film, every keystroke is an adventure, any innocent tag insertion into a Derridian deconstruction, whose matches of his previews with the reality are pure coincidence.