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.

Mi vision for a single high level language for the web and the cloud

The question of either to write code server side or browser side is more than a question, it is a problem. Either way, you will end up rewriting code from one side to the other because you suddenly will realize that to add something to that functionality in the server, you need something from the client and vice versa, after some changes you will realize that your functionality in the client would run better in the server or the other way around, so you will rewrite code back and forth from the server to the client and viceversa.

The underlying problem

The underlying problem is the lack of a  high level language both for the Web and the cloud, that can run in the server and in the browser, so that no code rewrite is necessary for communication locally or remotely, so each piece of functionality can be migrated at installation time depending on the capabilities of each node. Or.. better, at runtime, depending on capabilities and load conditions, from the server to the client and back. It can be done. It is something that I have been after since I started coding Web applications. First I tried it to design such a system with javascript, but at that time nothing in the Web architecture were mature enough.

The Web

MFlow and hplayground are a server and a client haskell Web frameworks respectively. Both share the same syntax and semantics, that is, almost the same code for the creation of pages and for the creation of dynamic effects in them. MFlow can perform almost all the page dynamic effects with or without ajax and javascript, using full page refresh when AJAX is not available .  Hplayground can perform richer reactive, dynamic effects since all the code has been compiled to javascript.

In my roadmap I plan to create a hplayground module for MFlow, with a single modifier, call it "client", that will compile the MFlow code to javascript using hplayground libraries and will run it in the browser. Otherwise it will behave as any other MFlow page procedure. Later that process of segregation will be automated; There will be no "client" modifier and any presentation code can be translated to javascript and can run in the browser, depending on the capabilities of the browser, load conditions, bandwidth etc.

Cloud:

MFlow has the FlowM monad, that can perform tracking, backtracking and long running transactions.  See this article:

How Haskell can solve the integration problem - FP Complete

These effecta are very important for the creation of loosely coupled architectures where exceptional conditions are not only exceptional, they also may be a part of the flow.  Conceptually a web application is a loosely coupled application with a server and a browser, where the client interrupt and send requests and responses in any order. To deal with that, the FlowM monad has these tracking, backtracking and state management effects. These are the very same effects necessary for dealing with communication failures, error conditions or transaction rollbacks from other MFlow nodes and/or databases without resorting to the spaghetti code of event handlers and a centralized updated state. Like in the case of web frameworks,  spaghetization precludes the programming of cloud framework such is Cloud Haskell at a higher level.

In my roadmap is the creation of MFlow node communication for synchronization and inter-node data access, using the web first, and later cloud Haskell as communication means, so that clusters of MFlow nodes share the processing load and the data access load. At the end all the cloud distribution of resources will start in a single program in a single node. The distribution of data and procedures will be automatic. I will add a "remote" modifier to distribute MFlow procedures. Later this remote modifier will disappear and it will be automatic, just like in the case of the "client" modifier for the browser. But this time these application would not be focused in web applications but any kind of them.

This may sound too ambitious. In fact that was never my goal, but a goal of the developer community. I always found it desirable and realizable, but not by me alone. However I  never imagined that I would realize it to the level that I've already done. I ever thought that this  would be done by other people. 

Who knows maybe I can see it realized. Maybe I find more people to join this vision. God will say.

UPDATE 03/09/2015  instead of cloud haskell, I developped my own distributed architecture, that is higher level; Transient:

http://github.com/agocorona/transient

Transient is based on the hplaygroud monad for handling events reactively. An event can be a mouse click, but also the arrival of data through a socket.  The MFlow web server and and navigation can be implemented on top of that so the dream is closer to reality.

Spreadsheet-like program in the browser using loeb iteration and loop resolution

I finally did what I was trying to do: to add full spreadsheet like effects to hplayground the haskell-javascript framework that uses the haste compiler

See the example running:

http://tryplayg.herokuapp.com/try/spreadsheet.hs/edit

I used the tryplayg IDE to develop the example and It works well. I have to improve it a lot however.

This program calculates speed, time and space. Each one depends on the other two. Each cell has two values: his current entered value and the expression which  calculates it from other cell values/expressions.  circularity is permitted.

The Cell recalculation code uses the famous loeb expression by Dan Piponi in the 2006. Until now by my knowledge there have'nt been any materialization of this formula on a real working spreadsheet. this one is close to it. Since loeb enters in a infinite loop when circular expressions are used, the program counts the loops and reduces complexity by progressively substituting formulas by cell values until the expression has no loops

This program is configured for immediate recalculation on cell change, but that can be adapted to allow the modification of more than one cell before recalculation by triggering it by means of a button.

IDE for Haste projects

I finished an Elm-like IDE for Haste projects. Haste is a compiler from Haskell to Javascript. The software is at: 

https://github.com/agocorona/tryhplay

Running in a heroku instance with a simple example:

http://tryplayg.herokuapp.com/try/console.hs/edit

Besides to edit-compile and run, it can also import , compile and run haste projects from git repositories (Although this, like the rest of the project is experimental).

I use it for my hplayground framework but it can run any haste project.

Using playground is easy to translate console programs to the browser and have reactive effects

A simple example:

http://tryplayg.herokuapp.com/try/fact.hs/edit

the hello-haste example:

http://tryplayg.herokuapp.com/try/hello-haste.hs/edit

Or something more complicated: the todo application, from todoMVC.com written in Haste and hplayground:

http://tryplayg.herokuapp.com/try/todo.hs/edit

rename the programs if you modify them. Follow the instructions to download the HTML generated, that include the Javascript generated. At this time there are no permission controls so it is more or less like a wiki, but heroku from time to time will reset the application.

It is a free instance on heroku so expect delays and request timeouts when many people access to the application. I do not know what will happen.  Feedback welcome

My heroku instance is limited but It is easy to create your own instance in heroku. Follow the install instructions. At:

https://github.com/agocorona/tryhplay/blob/master/README.md

A monad for reactive programming at SOH

Functional reactive programming has no notion of event scope. A functional, declarative, reactive computation is affected as a whole by a signal, and must re-start from the beginning in some way, since it is declarative. A monad can contain the scope of the signal, so part of the computation already done, upstream, do not change when a signal is injected at some level of the computation by an active component.

A monad can decompose the computation in a chain of event handlers virtually set up by the monadic computation when it is called by the top signal, that is, when it is run for the first time. This has many applications, not only in web programmin. I present a mook-up of a comercial application:

A monad for reactive programming  at SOH