Tuesday, September 16, 2014

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.


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

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, son 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 though 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.

Saturday, September 13, 2014

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:

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.

Friday, September 05, 2014

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: 

Running in a heroku instance with a simple example:

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:

the hello-haste example:

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

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:

Friday, August 08, 2014

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

Thursday, August 07, 2014

Running MFlow applications on Heroku

I updated this entry


Since the method no longer work since it produce timeouts with the modern version of some external libraries. Now the procedure uses anvil and works.

Tuesday, July 29, 2014

New TODO application for the hplayground client side framework. Feedback welcome

todoMVC.com created a reference application for testing and comparing client side frameworks. 
Well. I did the one for haplaygroud:
You can compare this code with the one of other frameworks. Feedback welcome.
The hplayground git site:
Some little bugs remain.
hplayground is a haskell framework that compiles to JavaScript (or to HTML directly) using a Haskell to JavaScript compiler : haste.
hplayground code has full reinversion of control. The code look like a console application with no event handlers. It is oriented towards rewrites of the HTML.DOM rather than to achieve dynamic behaviours by means of changing class attributes and hiding elements. therefore the dynamic effects, like edition of entries etc are done in such a way. 

Tuesday, July 01, 2014

hplayground: write haskell code for the browser console-like and have reactive, window and spreadsheet effects for free

Well this is the time to report something and get some feedback.

I have been trying to port the formlets concept to the client side with a lot of success. I think. The applicative and monadic code of  the MFlow widgets works almost unchanged when compiled to Javacript with the haste compiler.

I called it hplayground since it is more marketable than  Haskell-js-reactive-widgets . And it seems to me something that convert the browser into a playground to essay different things. The DOM tree structure, the HTML formatting, the events,  are not an impediment for making simple things simply. It helps  making complicated things easy since all of them work in harmony.

The examples are alive here:

What i achieved?  the possibility to create applications in the browser as fast as easy as console applications and have console, reactive, window-oriented and spreadsheet-like behaviours for free. The mix is a weird but powerful programming something. A kind of having your cake and eat it too.

The problem with the current haskell/elm reactive-declarative developments in the client side is as follows: They all create static layouts with holes that will be modified declaratively expressing reactive dependencies.  The result is that  page content can not be modified, except the holes.

I want everything, including the layout, to be modifiable by the  events.  and this means monadic code. And this means that the layout and the events must run across ifs, elses, case and branches of the code.

The hplayground idea is to use applicative code for static layouts but also monadic code for dynamic updates The events propagate downstream within the monadic code. Whenever that a widget raises an exception, the rest of the monadic computation is triggered, generating new rendering. The events, the computation, the HTML.DOM modifications of the layout follows the same natural and intuitive path within the monadic computation.

This is an static layout with to input boxes with a dynamic part at the end that show the results when the two input boxes validates:

sumtwonumbers = p "sum two numbers and append the result" ++>
  (p <<< do
     r <- (+) <$> inputInt Nothing `raiseEvent` OnKeyUp <++ br
              <*> inputInt Nothing `raiseEvent` OnKeyUp <++ br
     p <<< fromStr "result: " ++> b (show r) ++> return())

This is a combination of applicative (static) and monadic (dynamic) layout with reactive event handling. When one of the two fields receive a character, the result is updated. If some of the input boxes do not validate, the result line is deleted. It appears when the two boxes validate again.

inputInt :: Maybe Int -> Widget Int

How that happens?  raiseEvent attach an event handler to the input box.  This event handler i re-executes the the current widget and the  rest of the monadic computation down. This rest of the computation rewrite the HTML that generated previously, in this case, the result. So result is erased and rewritten when one of the two input boxes are modified.

raiseEvent :: :: Widget a -> HasteEventType ->Widget a

the layout: 'br' 'p' and the input box etc are  elements of the haste-perch library, described in the previous post.  They are added to the active input elements by means of operators for enclosing (<<<)  prepending (++>)  and postpending (<++).  

<$> and <*> are ordinary applicative combinators and (+) is the sum.

So events, layout and computation follow the same path. You can see a more complex example:

recursivesum :: Widget ()
recursivesum = p "sum recursively n numbers. When enters 0, present the result" ++> sumr 0
  sumr r=do
    r' <- inputInt Nothing `raiseEvent` OnKeyUp
    if r'== 0
      then br ++> fromStr "result: " ++> b (show r) ++> empty
      else do
        b (show $ r+r') ++> br ++> return ()
        sumr (r+r')

Here there is a input box. Initially it is empty so it does not validate and the computation stop there. If the user  enter 0, it present the result. If not it call itself recursively, so it creates another input box and so on. Until 0 is entered and the current sum is presented again below the last input box. If you change an intermediate value in a input box above you can see that the following input boxes are deleted, since the event handler deletes the layout of the continuation and rewrite it. 

There is a version in the examples that remember the old entries using a session context.

This example has a fixed number of input boxes:

sumfold n = p ("This widget sum "++ show n ++" numbers and append the result using a fold") ++>
       (p <<< do
         r <- foldl (<>) (return 0) . take n $ repeat $ inputInt Nothing `raiseEvent` OnKeyUp <++ br
         br ++> fromStr "result: " ++> b (show r) ++> return ())

Since Widget a is a instance of monoid as long as a is a Monoid,  any number of them can be folded.
Graphics are possible also, no news here, since the canvas internal layout is managed by his own monad in Haste. And that is right. However if you look at the "function draw" example and the "gallery" example you can see that the canvas is erased and recreated when the input boxes or a timeout event arrives. The reactive effect of the function draw example is noteworthy.
One more example: The pascal triangle:
-- pascal triangle http://www.haskell.org/haskellwiki/Blow_your_mind
pascal = iterate (\row -> zipWith (+) ([0] ++ row) (row ++ [0])) [1] :: [[Int]]
showpascal n= p << ("Show " ++ show n ++ " rows of the Pascal triangle ")
   ++> mconcat[p ! atr "style" "text-align:center" $ row | row <- take n pascal]
   ++> empty -- the applicative empty === noWidget

Things are not yet finished. I have to create an MFlow application for people to play with the idea. I have to upload the last version of the examples to the page 

Where these examples can be seen in action

I have to manage mouse events. It probably will use the same semantics than the wtimeout call, used in the gallery example.

Finally, for the updates of non local elements of the layout that not follow the default downstream flow of a monadic computation (think for example on something like a spreadsheet) Some of them can be done using Haste.DOM primitives , but I have to create high level abstractions like the cell concept. But I have not finished it yet.

By the way, Haste works like a charm. It produces short efficient code. All the examples fit in 100k of javascript code.

At this moment only text boxes and buttons work.  I have to add the dropdowns option buttons and wlinks.  so that full window like applications can be created. I just follow the path of higher resistance and leave the easy things for later.

An finally, some day I will take time to make my presentations, my examples and my texts more readable and more pretty and at least not as dyslexic as they are, but God did not called me to go this path. Too busy programming. Blogger conspirates against me, but I have no clue about what happens with the layout of this page.

To summarize, with little more effort that what you would employ in the creation of a console application and with the same structure, you can create a live dynamic application running in any browser.