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

http://haskell-web.blogspot.com.es/2013/05/running-mflow-applications-on-heroku.html

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:
https://github.com/agocorona/hplayground
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:
http://mflowdemo.herokuapp.com/noscript/wiki/browserwidgets

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
  where
  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.

Friday, June 06, 2014

Taming the HTML DOM with monads and monoids

Haste is a compiler that generates Javascript code from Haskell.
The Haste.DOM module define a thin layer over the JavaScript DOM. That makes the creation and manipulation of DOM elements as painful as in JavaScript. The reason is because to add an element it is necessary two steps: to create the element and get the reference to that elemen, and to append the element as child of the parent.  This linking of references by hand is what makes the creation of dynamic HTML hard, tedious and inelegant.
That is why all the Haskell-Javascript compilers have static HTML demos most of the time, and they concentrate in the creation of graphics, that CAN be programmed in a more pleasant way.
This package makes the creation of DOM elements easy with a syntax similar to other haskell HTML generators, using monoids and monads, such is the case of the package blaze-html.
This is an example. withElem is a Haste.DOM call that give the DOM object whose id is "idelem", that has been created "by hand" in Main.hs. The builder that I created (see the link below) takes this element and add content by defining a hierarchy within the `JSBuilder` monad:
  main= do
   withElem "idelem" . build $ do
    div $ do
       div  $ do
           p "hello"
           nelem "p" `attr` ("style","color:red")  `child`  "world" 
    return ()

   div cont=  nelem "div" `child`  cont

   p cont = nelem "p"  `child`  cont
`child` and `nelem` are defined in the builder too.

No element references have to be managed by the programmer unlike in the case of the plain DOM interface. Try to do it using plain DOM calls.

The output in the browser is:
NOTE: blogger is sooo ugly . Execute it and look at the HTML code for yourself.
The HTML rendering is:
hello
world
How it works? The basic element is a  `builder ` data type that has a "hole" parameter and a IO action which creates the element. The hole contains the parent (Elem) of the element being created.

newtype JSBuilderM a= JSBuilder{build :: Elem -> IO Elem} deriving Typeable
type JSBuilder = JSBuilderM ()
The phanton type 'a' is in order make a valid monad instance of JSBuilderM with the appropriate kind. Nothing more.

Upon created, the elem is added to the parent and return itself as parent of the next elements. That is the creation of an element:

nelem s= JSBuilder $ \e ->do
    e' <- newElem s
    addChild e' e
    return e'

To append two elements,  it executes the build-link procedure defined for each element to the parent, and return the parent node:

instance Monoid (JSBuilderM a) where
    mappend mx my= JSBuilder $ \e -> do
         build mx e
         build my e
         return e
    mempty = JSBuilder return
The expression:

build mx e

Executes the IO computation for the creation of the element/elements included (it may be a sub-tree). 

To add a child, the parent's computation is executed, the chid is converted into a builder (using a ToElem instance) and the builder is executed taking the parent as parameter. Finally the parent is returned


child :: ToElem a => JSBuilder -> a -> JSBuilder
child me ch= JSBuilder $ \e' -> do
        e <- build me e'
        let t = toElem ch
        .build t e
        return e

Similarly, to add an attribute to an elem:


attr tag (n, v)=JSBuilder $ \e -> do
        tag' $lt;- build tag e
        setAttr tag' n v
        return tag'

The Monad instance is there in order to use the do notation.  This add a new level of syntax, in the style of the package blaze-html. This monad invokes the same appending mechanism.
This makes the creation of dynamic Web apps in the browser with texts and formatting far more easy, as a seamless declarative sequence with the shape of the DOM three being created, rather than as a imperative sequence full of seams.
The equivalent monoid expression can also be used, by concatenating elements with the operator <> or mappend

I guess this technique can be generalized for the creation of any tree data structure and any kind of tree management primitives.
The code and how it works, the demo etc is here:
https://github.com/agocorona/haskell-js-html-builder

UPDATE:
this software is now called "perch" and is published in the hackage repository. It support now the same syntax than blaze-html including attribute (!) operators etc.

https://hackage.haskell.org/package/haste-perch

Friday, May 30, 2014

Separation of concerns by the problem domain, not by tecnology - Composable caching

The "separation of concern" -as is understood by MVC Web frameworks- does not  separate concerns really. A separation of concern forced by  technological problems rather than being separated by components of the problem domain is like saying that I live better as an slave because I have no need to be concerned by how good or bad the master behave. Caching is an example of this contradiction.

The MVC model forces his own separation of concern and it is inherently non composable. It does not allow to create self contained elements -with M V and C components inside- that can be composed to create applications. That means that it can not separate the concerns in terms of application functionalities: login, payment, content management, lazy loading,  auto-completion widgets etc. As well as other functionalities specific of the individual application. The separation is dictated from below. That is because the technologies involved: event-driven graphical presentation, transactional data management and business logic are not yet fully integrated. See: Towards a deeper integration: A Web language

Concerning caching, A HTTP guru, probably in other department does not know for how long your particular data is valid . Neither you know if the HTTP guru will cache your fresh data in order to avoid loading the server, so you will add a random string to your data to avoid caching. In any case, there is a opportunity lost for optimizing the load of the server without impairing the interaction.

Now the new composable caching policies of MFlow permits the use of aggressive caching policies even for highly dynamic pages, since expressing cache directives is in the hands of the programmer of each particular widget. 

What if you, the programmer of a widget can say to the page: "this widget present data that can be cached for 200 seconds, no matter if it is part of a page or if its data is sent trough Ajax". Or: "the user has logged-in so this page must be private, no matter the policies of the rest of the widgets".
What if the page can get all the cache policies of all the widgets and insert the most restrictive ones in the HTTP header?

Then we would have a true separation of concern without impairing synergies.

If the widget is refreshed using ajax, only the individual cache policy of the widget is taken into account. For example: I´m logged here as editor, so the login widget detect this condition and mark the page as private. But If I click an autorefreshed widget which is not marked as private and have a maxAge directive, the menu options on the left, for example, then the menus can be cached within network proxies and CDNs, so other users can make use of these cached resources without compromising my privacy.

Going this way, more synergies appear in unsuspected ways;  What is the killer application of the JavasCript frameworks?  To present data sets without repeated accesses to the server using the new HTML5 cache.  Now this can be done by caching AJAX responses in the good old HTTP cache, and make it work in any browser without explicit JavaScript programming.

Because blogger is almost impossible to tame for me. I leave a link to the full article about composable caching in the MFlow demo site:

http://mflowdemo.herokuapp.com/noscript/wiki/cachingdfield




Friday, April 04, 2014

Towards a deeper integration: A Web language

When I wrote the article "How to solve the integration problem", in which I assimilate web development to a general integration problem, I was not fully conscious of how true it was. Web development is becoming increasingly a problem of integration of different technologies, languages paradigms and applications. Consciously or unconsciously web developers view web applications as a problem of integration. as essentially the development and integration of two or three independent applications: one in the browser, other in the server and maybe another in the database, with a dozen configurations that glue these things together.

That implicitly precludes the effort in the search for a higher paradigm that can be found by a deeper integration. That leaves essentially unresolved the problem of creating a true Web framework: A Web language. A framework in which the fundamental building block has data navigation presentation and storage and whatever other thing necessary inside itself. This building block that has all the components integrated, may be composed to build true web applications.

The situation is similar to the time when there were only batch systems.  There was no unification of input, processing and output. the programmer created a job  in a set of punched cards. The output of he job was sent to a printer. There were no interactive input-output. there were a input program, a processing program and a printing program. The applications ran essentially in the same way as a stateless web service  work.

Then, interaction was added. both input and output streams were intermixed. state was added. Each programming component may alternate repeated input and output interactions. When there were previously only batch processes, then there were development environments, shells, games etc. 

The building block for console applications had a higher level than the one of previous batch developments. The programmer managed abstractions in terms of the problem not in terms of the phase in the process in which the batch was executing for the hardware needs. That was because a new composable piece was found: the IO procedure, that combined input and output. The IO calls were a product on this revolution. that was a true revolution since it was an inversion of control where the program was in control of the flow. And a new kind of application was born: the interactive console application.

But essentially the IO procedure was the combination of small batch programs: the OS and library calls.  We don´t think on these small pieces as programs. we are so accustomed to work with pieces at a higher level that we do not even consider that. 

Can we do the same for the Web?. One may say that this new de-inversion of control will produce problems of scalability, state handling etc. All this is true. But they are the very same problem that the Operating systems had when switched from batch to interactive applications:  the batch systems did not leave state behind. They were fine and reliable. But people though that batch systems were not enough.

Can we do the same for the Web?. Unlike console applications. In Web applications the user must be in control, not the program. But the programmer must feel that he is in control of the flow.

That is not only possible, but highly desirable. If the fused building block is composable, we would have the Rosetta Stone of integration, a new unified language upon which to talk at a higher level with the machines for building web applications and since web applications are a particular kind of application integration, we can extend it to any kind of integration problem, as I mentioned in the article above.

Furthermore, if the building block and the composition make use of well known ideas then the task of making that language understandable becomes far more easy.

And now the marketing part. Excuse the bombastic tone, required in any marketing activity:

In the article mentioned above, I claim that MFlow do it. It is a Web language.  The MFlow building blocks are the widgets and the flow elements, (flowlets). A widget is an applicative or monadic piece of code with  a parser of request parameters and a writer of HTML code. It combines the creation of rendering, request parsing, processing and session management among other in a single atomic composable element. In the other side, a flowlet manage reusable and composable flows of pages, with state management.

People that know how to program monadic parsers will find natural how the MFlow monadic widgets works. People that know how to use formlets will find natural how applicative widgets behave.  If an user know how to create imperative code, he can create page navigations.

And the deep fusion of elements will give the opportunity to create easier solutions to known problems.

Soon I will add composable caching directives to MFlow, where a widget can express its own HTTP caching needs to the page, and I will show an example that uses this for caching javascript programs generated in the server by the haskell code to navigate a dataset without repeated accesses to the server.

Stay tuned.