- web-devel - Haskell.org

Making throughput much better
by Kazu Yamamoto 22 Jul '13

22 Jul '13

Hi all, Cc: Simon Marlow I think I found a way to make the throughput of web servers much better. In short, put "Control.Concurrent.yield" after sending something. This enables good schedule shaping. Typical code for web servers is like this: loop = do keepAlive <- receiveRequest sendResponse when keepAlive loop With this code, a typical sequence of system calls is like this: recvfrom(13, ) -- thread A sendto(13, ) -- thread A recvfrom(13, ) = -1 EAGAIN -- thread A epoll_ctl(3, ) -- IO manager recvfrom(14, ) -- thread B sendto(14, ) -- thread B recvfrom(14, ) = -1 EAGAIN -- thread B epoll_ctl(3, ) -- IO manager Since each thread calls recvfrom() immediately after sendto(), the possibility that recvfrom() can receive a request is low. This involves the IO manager. To make the possibility higher, I put "yield" after sendResponse: loop = do keepAlive <- receiveRequest sendResponse yield when keepAlive loop Yield pushes its Haskell thread onto the end of thread queue. So, another thread can work. During the work of other threads, a request message would arrive. recvfrom(13, ) -- thread A sendto(13, ) -- thread A recvfrom(14, ) -- thread B sendto(14, ) -- thread B recvfrom(13, ) -- thread A sendto(13, ) -- thread A I tested this idea on SimpleServer and confirmed that its throughput is doubled: No yield: 58,152 req/s (https://gist.github.com/AndreasVoellmy/4184520#file-simpleserver-hs) Yield: 113,048 req/s (https://gist.github.com/kazu-yamamoto/6051118#file-simpleserver2-hs) Unfortunately, yield does not work for Warp as expected. It does not pass control to another thread and behaves as used to be. So, my question: why doesn't "yield" work in Warp? ResourceT is doing a special thing? My code change is here: https://github.com/yesodweb/wai/commit/4e9c6316ad59cd87be13000d15df8e6fd7c3… I'm using GHC head (with multicore IO manager). I'm sure that the following patch to fix the bug of yield is applied: https://github.com/ghc/ghc/commit/66839957a376dbe85608822c1820eb6c99210883 P.S. It would be appreciated if someone tries this idea on other web servers. --Kazu

3 4

Automatic error traces
by Alberto G. Corona 18 Jul '13

18 Jul '13

It is important to have execution traces in case of error. specially in server applications that run 24/7 such are web applications Thanks to the wonderful package monadloc by Pepe Iborra, now MFlow can generate a complete execution trace in case of error. The control-monad-exception uses monadLoc to generate stack traces, but MFlow makes use of his backtracking mechanism to generate a complete execution trace. Here I explain what and how: http://haskell-web.blogspot.com.es/2013/07/automatic-error-trace-generation… The MFlow version that implements this is in gitHub. Not in hackage yet. https://github.com/agocorona/MFlow I´m quite proud of it since it is one of the things closest to magic that I have done. Feedback? I do not want to keep MFlow as a single person development. I think that it has many unique and nice features not available in other languages and frameworks, and it can be raised to a serious exploitation level by the Haskell community. This will attract people working in Industrial Web development to Haskell thanks to the edge in expressiveness and safety necessary for creating industrial solutions that Haskell has over other languages. It uses most other Haskell web developments blaze, wai, hamlet etc and there are many other things to come. monadLoc : http://hackage.haskell.org/package/monadloc -- Alberto.

2 3

Re: [web-devel] [Haskell-cafe] ANNOUNCE: MFlow 3.0
by Alberto G. Corona 13 Jul '13

13 Jul '13

My plan is to synchronize MFlow servers using cloud Haskell since the state serialization is small. I´m working on it. However continuation based frameworks can not synchronize state. There is "swarm" in scala that generate portable continuations but this is not used in the context of web application since the state in a continuation is big and can not be synchronized fast enough. In other languages these states are not even portable between machines. 2013/7/10 Alexander Kjeldaas <alexander.kjeldaas(a)gmail.com> > Here are some common-lisp web frameworks using continuations: > > http://common-lisp.net/project/cl-weblocks/ > http://common-lisp.net/project/ucw/features.html > > What always worried me with these frameworks is how they could be made > robust in case of failures. Storing all state in a database backend often > makes it possible to isolate failures. However, it seems to me that it is > be possible to solve this in Haskell where state can be serialized and > synchronized between multiple machines using Cloud Haskell, something that > is error-prone or impossible in other languages. But that step has never > been taken. > > Alexander > > > On Wed, Jul 10, 2013 at 4:48 PM, Alberto G. Corona <agocorona(a)gmail.com>wrote: > >> Thanks Adrian. The racket people where pioneers in this idea I think. >> >> There is another web framework in Ocaml, Osigen that it is also >> continuation based. MFlow is not continuation-based but it also define the >> navigation as a sequence. But only Seaside (and now MFlow) supports many >> flows in the same page. See for example this: >> >> [PDF] *Seaside* – A *Multiple* Control *Flow* Web Application Framework<http://www.google.es/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=3&cad=rja…> >> >> There is also other: Apache Coccoon that run in a special kind of >> JavaScript. The continuation-based frameworks have the reputation of >> storing a lot of application state and to be non scalable. MFlow >> uses backtracking and It does not have these problems. >> >> >> 2013/7/10 Adrian May <adrian.alexander.may(a)gmail.com> >> >>> Oh how nice! >>> >>> I have been looking at MFlow a lot lately and I think it's got something >>> quite special that Yesod, Happstack, etc don't seem to have, at least, not >>> as far as I know. I mean, look at this: >>> >>> sumWidget= pageFlow "sum" $ do >>> >>> n1 <- p << "Enter first number" ++> getInt Nothing <** submitButton "enter" <++ br >>> >>> >>> >>> >>> >>> n2 <- p << "Enter second number" ++> getInt Nothing <** submitButton "enter" <++ br >>> >>> >>> >>> >>> >>> n3 <- p << "Enter third number" ++> getInt Nothing <** submitButton "enter" <++ br >>> >>> >>> >>> >>> >>> p << ("The result is: "++show (n1 + n2 + n3)) ++> wlink () << b << " menu" >>> >>> >>> >>> >>> >>> <++ p << "you can change the numbers in the boxes to see how the result changes" >>> >>> Is that pretty or what? That's the code for this: >>> >>> http://mflowdemo.herokuapp.com/noscript/fviewmonad >>> >>> To me that's a real technological step over and above the usual servlets >>> paradigm and I'd love to see more people getting involved. It seems like >>> Yesod and Happstack have a lot more manpower behind them, but unless I've >>> missed something, MFlow is going somewhere new and should be helped along. >>> >>> Adrian. >>> >>> PS. Besides Seaside, Racket is playing with the same ideas. They (Jay >>> McCarthy) have something to say about performance but I didn't quite >>> understand it. >>> >>> >>> >>> On 10 July 2013 06:41, Alberto G. Corona <agocorona(a)gmail.com> wrote: >>> >>>> The third version of MFlow is out. >>>> >>>> http://hackage.haskell.org/package/MFlow >>>> >>>> MFlow is an all-heterodox web application framework, but very >>>> haskellish. >>>> >>>> Now MFlow support restful URLs. It is the first stateful web framework >>>> to my knowledge that supports it. The type safe routes are implicitly >>>> expressed as normal monadic code within a navigation monad. The application >>>> look as a normal imperative console application, but the navigation monad >>>> goes back and forth to match the path of the URL. The user has control of >>>> the state, that can roll-back or not when the navigation goes back >>>> depending on the application needs. The state is in the form of normal >>>> Haskell variables In a monadic computation, with the weird addition of >>>> backtracking. >>>> >>>> The menu of the application below is implemented as an imperative-like >>>> syntax, but the application navigate forward and backward to synchronize >>>> with the requests of the web browser: >>>> http://mflowdemo.herokuapp.com/ >>>> >>>> This version support in-page flows. >>>> What is that? look at this example: >>>> >>>> http://mflowdemo.herokuapp.com/noscript/fviewmonad >>>> >>>> These flows are implemented as formlets with a monad instance, and >>>> callbacks which change the look. I call them "widgets": >>>> >>>> >>>> http://haskell-web.blogspot.com.es/2013/06/the-promising-land-of-monadic-fo… >>>> >>>> >>>> Each page may have many of these active widgets, each one running >>>> their own flow. These widgets refresh themselves trough Ajax if they are >>>> enclosed in the primitive "autoRefresh". If there is no Ajax or JavaScript >>>> available, they gracefully degrade by refreshing the entire page: >>>> >>>> http://mflowdemo.herokuapp.com/noscript/combination >>>> >>>> >>>> http://haskell-web.blogspot.com.es/2013/06/and-finally-widget-auto-refreshi… >>>> >>>> The page flows and the multiflow idea was inspired in Seaside<http://www.seaside.st/>, >>>> a great Smalltalk web framework and adapted to the pure recursive nature of >>>> Haskell and the formlets. >>>> >>>> It also support some JQuery widgets integrated: modal and not modal >>>> dialogs, datePicker and other active widgets that handle other widgets. >>>> >>>> It also support the older features: persistent state, WAI, blaze-html >>>> and others integration, server process timeouts, Ajax, requirements, >>>> content management, caching of widget rendering and all the other >>>> previous stuff. >>>> >>>> I wish to thank some people for their feedback. Specially Adrian May >>>> for his feedback and interest >>>> >>>> >>>> -- >>>> Alberto. >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >>> >> >> >> -- >> Alberto. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > -- Alberto.

1 1

Re: [web-devel] [Haskell-cafe] ANNOUNCE: MFlow 3.0
by Alberto G. Corona 13 Jul '13

13 Jul '13

I factored out the submit buttons. Now the three text boxes appear in succession above a unique button below. http://mflowdemo.herokuapp.com/noscript/fviewmonad This is the new code: sumWidget= pageFlow "sum" $ do n ← (do n1 ← p << "Enter first number" ++> getInt Nothing <++ br n2 ← p << "Enter second number" ++> getInt Nothing <++ br n3 ← p << "Enter third number" ++> getInt Nothing <++ br return (n1+ n2 + n3)) <** pageFlow "button" (submitButton "submit") p << ("The result is: "++show n) ++> wlink () << b << " menu" <++ p << "you can change the numbers in the boxes to see how the result changes" 2013/7/10 Adrian May <adrian.alexander.may(a)gmail.com> > Oh how nice! > > I have been looking at MFlow a lot lately and I think it's got something > quite special that Yesod, Happstack, etc don't seem to have, at least, not > as far as I know. I mean, look at this: > > sumWidget= pageFlow "sum" $ do > > n1 <- p << "Enter first number" ++> getInt Nothing <** submitButton "enter" <++ br > > n2 <- p << "Enter second number" ++> getInt Nothing <** submitButton "enter" <++ br > > n3 <- p << "Enter third number" ++> getInt Nothing <** submitButton "enter" <++ br > > p << ("The result is: "++show (n1 + n2 + n3)) ++> wlink () << b << " menu" > > <++ p << "you can change the numbers in the boxes to see how the result changes" > > Is that pretty or what? That's the code for this: > > http://mflowdemo.herokuapp.com/noscript/fviewmonad > > To me that's a real technological step over and above the usual servlets > paradigm and I'd love to see more people getting involved. It seems like > Yesod and Happstack have a lot more manpower behind them, but unless I've > missed something, MFlow is going somewhere new and should be helped along. > > Adrian. > > PS. Besides Seaside, Racket is playing with the same ideas. They (Jay > McCarthy) have something to say about performance but I didn't quite > understand it. > > > > On 10 July 2013 06:41, Alberto G. Corona <agocorona(a)gmail.com> wrote: > >> The third version of MFlow is out. >> >> http://hackage.haskell.org/package/MFlow >> >> MFlow is an all-heterodox web application framework, but very haskellish. >> >> Now MFlow support restful URLs. It is the first stateful web framework >> to my knowledge that supports it. The type safe routes are implicitly >> expressed as normal monadic code within a navigation monad. The application >> look as a normal imperative console application, but the navigation monad >> goes back and forth to match the path of the URL. The user has control of >> the state, that can roll-back or not when the navigation goes back >> depending on the application needs. The state is in the form of normal >> Haskell variables In a monadic computation, with the weird addition of >> backtracking. >> >> The menu of the application below is implemented as an imperative-like >> syntax, but the application navigate forward and backward to synchronize >> with the requests of the web browser: >> http://mflowdemo.herokuapp.com/ >> >> This version support in-page flows. >> What is that? look at this example: >> >> http://mflowdemo.herokuapp.com/noscript/fviewmonad >> >> These flows are implemented as formlets with a monad instance, and >> callbacks which change the look. I call them "widgets": >> >> >> http://haskell-web.blogspot.com.es/2013/06/the-promising-land-of-monadic-fo… >> >> >> Each page may have many of these active widgets, each one running their >> own flow. These widgets refresh themselves trough Ajax if they are enclosed >> in the primitive "autoRefresh". If there is no Ajax or JavaScript >> available, they gracefully degrade by refreshing the entire page: >> >> http://mflowdemo.herokuapp.com/noscript/combination >> >> >> http://haskell-web.blogspot.com.es/2013/06/and-finally-widget-auto-refreshi… >> >> The page flows and the multiflow idea was inspired in Seaside<http://www.seaside.st/>, >> a great Smalltalk web framework and adapted to the pure recursive nature of >> Haskell and the formlets. >> >> It also support some JQuery widgets integrated: modal and not modal >> dialogs, datePicker and other active widgets that handle other widgets. >> >> It also support the older features: persistent state, WAI, blaze-html and >> others integration, server process timeouts, Ajax, requirements, >> content management, caching of widget rendering and all the other >> previous stuff. >> >> I wish to thank some people for their feedback. Specially Adrian May for >> his feedback and interest >> >> >> -- >> Alberto. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Alberto.

1 0

Re: [web-devel] [Haskell-cafe] ANNOUNCE: MFlow 3.0
by Alberto G. Corona 10 Jul '13

10 Jul '13

Thanks Adrian. The racket people where pioneers in this idea I think. There is another web framework in Ocaml, Osigen that it is also continuation based. MFlow is not continuation-based but it also define the navigation as a sequence. But only Seaside (and now MFlow) supports many flows in the same page. See for example this: [PDF] *Seaside* – A *Multiple* Control *Flow* Web Application Framework<http://www.google.es/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=3&cad=rja…> There is also other: Apache Coccoon that run in a special kind of JavaScript. The continuation-based frameworks have the reputation of storing a lot of application state and to be non scalable. MFlow uses backtracking and It does not have these problems. 2013/7/10 Adrian May <adrian.alexander.may(a)gmail.com> > Oh how nice! > > I have been looking at MFlow a lot lately and I think it's got something > quite special that Yesod, Happstack, etc don't seem to have, at least, not > as far as I know. I mean, look at this: > > sumWidget= pageFlow "sum" $ do > > n1 <- p << "Enter first number" ++> getInt Nothing <** submitButton "enter" <++ br > > n2 <- p << "Enter second number" ++> getInt Nothing <** submitButton "enter" <++ br > > n3 <- p << "Enter third number" ++> getInt Nothing <** submitButton "enter" <++ br > > p << ("The result is: "++show (n1 + n2 + n3)) ++> wlink () << b << " menu" > > <++ p << "you can change the numbers in the boxes to see how the result changes" > > Is that pretty or what? That's the code for this: > > http://mflowdemo.herokuapp.com/noscript/fviewmonad > > To me that's a real technological step over and above the usual servlets > paradigm and I'd love to see more people getting involved. It seems like > Yesod and Happstack have a lot more manpower behind them, but unless I've > missed something, MFlow is going somewhere new and should be helped along. > > Adrian. > > PS. Besides Seaside, Racket is playing with the same ideas. They (Jay > McCarthy) have something to say about performance but I didn't quite > understand it. > > > > On 10 July 2013 06:41, Alberto G. Corona <agocorona(a)gmail.com> wrote: > >> The third version of MFlow is out. >> >> http://hackage.haskell.org/package/MFlow >> >> MFlow is an all-heterodox web application framework, but very haskellish. >> >> Now MFlow support restful URLs. It is the first stateful web framework >> to my knowledge that supports it. The type safe routes are implicitly >> expressed as normal monadic code within a navigation monad. The application >> look as a normal imperative console application, but the navigation monad >> goes back and forth to match the path of the URL. The user has control of >> the state, that can roll-back or not when the navigation goes back >> depending on the application needs. The state is in the form of normal >> Haskell variables In a monadic computation, with the weird addition of >> backtracking. >> >> The menu of the application below is implemented as an imperative-like >> syntax, but the application navigate forward and backward to synchronize >> with the requests of the web browser: >> http://mflowdemo.herokuapp.com/ >> >> This version support in-page flows. >> What is that? look at this example: >> >> http://mflowdemo.herokuapp.com/noscript/fviewmonad >> >> These flows are implemented as formlets with a monad instance, and >> callbacks which change the look. I call them "widgets": >> >> >> http://haskell-web.blogspot.com.es/2013/06/the-promising-land-of-monadic-fo… >> >> >> Each page may have many of these active widgets, each one running their >> own flow. These widgets refresh themselves trough Ajax if they are enclosed >> in the primitive "autoRefresh". If there is no Ajax or JavaScript >> available, they gracefully degrade by refreshing the entire page: >> >> http://mflowdemo.herokuapp.com/noscript/combination >> >> >> http://haskell-web.blogspot.com.es/2013/06/and-finally-widget-auto-refreshi… >> >> The page flows and the multiflow idea was inspired in Seaside<http://www.seaside.st/>, >> a great Smalltalk web framework and adapted to the pure recursive nature of >> Haskell and the formlets. >> >> It also support some JQuery widgets integrated: modal and not modal >> dialogs, datePicker and other active widgets that handle other widgets. >> >> It also support the older features: persistent state, WAI, blaze-html and >> others integration, server process timeouts, Ajax, requirements, >> content management, caching of widget rendering and all the other >> previous stuff. >> >> I wish to thank some people for their feedback. Specially Adrian May for >> his feedback and interest >> >> >> -- >> Alberto. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Alberto.

1 0

ANNOUNCE: MFlow 3.0
by Alberto G. Corona 09 Jul '13

09 Jul '13

The third version of MFlow is out. http://hackage.haskell.org/package/MFlow MFlow is an all-heterodox web application framework, but very haskellish. Now MFlow support restful URLs. It is the first stateful web framework to my knowledge that supports it. The type safe routes are implicitly expressed as normal monadic code within a navigation monad. The application look as a normal imperative console application, but the navigation monad goes back and forth to match the path of the URL. The user has control of the state, that can roll-back or not when the navigation goes back depending on the application needs. The state is in the form of normal Haskell variables In a monadic computation, with the weird addition of backtracking. The menu of the application below is implemented as an imperative-like syntax, but the application navigate forward and backward to synchronize with the requests of the web browser: http://mflowdemo.herokuapp.com/ This version support in-page flows. What is that? look at this example: http://mflowdemo.herokuapp.com/noscript/fviewmonad These flows are implemented as formlets with a monad instance, and callbacks which change the look. I call them "widgets": http://haskell-web.blogspot.com.es/2013/06/the-promising-land-of-monadic-fo… Each page may have many of these active widgets, each one running their own flow. These widgets refresh themselves trough Ajax if they are enclosed in the primitive "autoRefresh". If there is no Ajax or JavaScript available, they gracefully degrade by refreshing the entire page: http://mflowdemo.herokuapp.com/noscript/combination http://haskell-web.blogspot.com.es/2013/06/and-finally-widget-auto-refreshi… The page flows and the multiflow idea was inspired in Seaside<http://www.seaside.st/>, a great Smalltalk web framework and adapted to the pure recursive nature of Haskell and the formlets. It also support some JQuery widgets integrated: modal and not modal dialogs, datePicker and other active widgets that handle other widgets. It also support the older features: persistent state, WAI, blaze-html and others integration, server process timeouts, Ajax, requirements, content management, caching of widget rendering and all the other previous stuff. I wish to thank some people for their feedback. Specially Adrian May for his feedback and interest -- Alberto.

1 0

The promising world of Monadic formlets
by Alberto G. Corona 22 Jun '13

22 Jun '13

Hi, This is just to let you know the promising results of some experimentation: Formlets are about applicative instances, but what about monadic instances? What a Monad instance of formlets means? I recently experimented with this and the results are very interesting and powerful- It mixes the best of web forms, with the flexibility of console applications. ???!!!!!! Althoug this example is for the formlets of the MFlow <https://github.com/agocorona/MFlow>framework , it can be ported to other formlet implementations. Although the MFLow formlets include web formatting that is not supported in other formlets implementations. Static HTML templating don´t work well with monadic formlets, so it is important to include the formatting as a part of the computation: import MFlow.Wai.Blaze.Html.All dynamicForm= wform $ do (n,s) <- (,) <- p << "Who are you?" ++> getString Nothing <! hint "name" <++ br <*> getString Nothing <! hint "surname" <++ br <** submitButton "ok" <++ br flag <- b << "do you " ++> getRadio[radiob "work?",radiob "study?"] <++ br r<-case flag of "work" -> pageFlow "l" $ Left <- b << "do you enjoy your work? " ++> getBool True "yes" "no" <** submitButton "ok" <++ br "study"-> pageFlow "r" $ Right <- b << "do you study in " ++> getRadio[radiob "University" ,radiob "High School"] p << ("You are "++n++" "++s) ++> case r of Left fl -> p << ("You work and it is " ++ show fl ++ " that you enjoy your work") ++> noWidget Right stu -> p << ("You study at the " ++ stu) ++> noWidget hint s= [("placeholder",s)] onClickSubmit= [("onclick","this.form.submit()")] radiob s n= text s ++> setRadio s n <! onClickSubmit Here wform, getBool, getString , getRadio etc are formlet elements The first sentence is an applicative composition that generate a 2 tuple, to show that applicative and monadic can be mixed. the operations ++> add html to the formlet. the operatior <! add attributes to the formlet element.. noWidget is a dumb formlet that does not validate. The second monadic statement is an election between two options. The beauty of the monadic instance is that the rest of the form can vary depending on the previous answers. Since the formlets validate the input, unless the election is made, the radio will not validate, so the monadic execution will be aborted beyond any unanswered question, so nothing will appear after the question. The rest of the form will appear when the user choose one of the two options. once one or the other option is chosen, then another binary question is presented. (either he likes his work or where he study). When the questions are finised, the results are presented. I hope that you get the idea. The benefit is not only the familiar coding and presentation of a sequential console application: Since the form encloses all the fields, At any time the user can change previous inputs and the form will reflect these changes. For example if the user change from work to study (second statements) the "where do you study will appear and the work related questions and answers will disappear. That is wonderfully useful for heavily interactive applications. There is a problem however and it is the issue of the formlet identifiers. Unlike in an applicative presentation, now the number and type of the formlets will vary, so the response to a previous form create a new kind of form, and the post response can be misinterpreted. To avoid that , the pageFlow call creates fixed field labels for each branch of execution. I will release a version of MFlow that support this kind of monadic composition of fomlets, but In essence it is nothing but to add Monad instance to formlets. A single server procedure, that executes the formlet code can support all the interaction so any framework can do it. The usability of that is huge:It is possible to interact in a web page in a console style with questions and answers with the versatitly of a dynamic foms: Any modification in the form change the subsequent flow of interaction. Another application of this monadic style is to ease multistep processes such are registration, check-out and payment ad so on. Even a entire interactive dynamic application can be coded in a single page. And no javascript is needed!. To run this formlet in MFlow: main=do addMessageFlows [("" , transient $ runFlow $ ask dynamicForm )] wait $ run port waiMessageFlow This video show how the presentation of this example vary with the user input: http://youtu.be/DryBQc9agFg I hope that you find the idea interesting. If you want to experiment with this in MFlow, I have to say that the implementation of this feature is in an early stage. The code is in the head branch https://github.com/agocorona/MFlow/tree/head Alberto.

2 3

Lista de aprova��o Cajueiro
by Edson 29 May '13

29 May '13

Lista de aprovação Cajueiro: Ribeirão Cascalheira: AMANDA SILVA DE MELO, LEONEL LOPES FERNANDES, FRANCISCO ALBERTO DA SILVA, PÂMELA VIRGÍNIA DE SOUZA, JOÃO CARLOS MOREIRA DE CARVALHO, DAISY CHRISTINE MELO NOGUEIRA, MARIA DENISE FEITOSA, JACQUELINE RAQUEL MENDES PATRIOTA. SAULO DEMIAN FERREIRA MAIA, ÉRICA BEZERRA DA SILVA, MAYRA FIGUEIRÊDO PEREIRA, JUAN JACKSON HOLANDA PONTE RIBEIRO, WESLEY ROGERIO ALVES. Lago do Junco. Cajueiro, ADELÂENNE KIRLEY, JULIANA RODRIGUES ALVES, ERICH DOUGLAS MOREIRA CHAVES, MAYSA RAQUEL DA SILVA, JOÃO CARLOS MOREIRA DE CARVALHO, CARLOS ALEXANDRE SILVA DE LIMA, MANOEL LEYVSON MACHADO MATOS, IANN MARZZO SAMPAIO LIBOS. ROBERTO BEZERRA FERREIRA, DIONE MARIA DA SILVA, MARIANA COSTA OLIVEIRA, JORGE ROBERTO PRUDENCIO NASCIMENTO, THALITA JESSICA FERREIRA DA ROCHA. Caeté. Nova Redenção e ANA CAROLINE LIMA VASCONCELOS, LÍVIO CHAVES DÔDÔ, FRANCISCO JACKSON DE FREITAS SOUZA, PAULO WILLAME ARAUJO DE LIMA, JOÃO CARLOS MOREIRA DE CARVALHO, DAMIÃO ROCHA DOS SANTOS JÚNIOR, MARIA HELENA DE OLIVEIRA SILVA, JARDEL DE LIMA NOBRE. SILVANA BEZERRA DA SILVA, ARIELA DE MACEDO RICARDO, LUCAS PINTO ASSUNCAO, GLAUCIO VALENCA PEREIRA RANGEL, REBECA FARIAS CARNEIRO. Itauçu.

1 0

Re: [web-devel] [Haskell-cafe] Fwd: Backward compatibility
by Alberto G. Corona 05 May '13

05 May '13

Well, the main one is that is in the group of continuation based frameworks, like other advanced web frameworks such are seaside (smalltalk) ocsigen (ocaml) or coccoon (JavaScript) . That means that it is not based on the event model, and the flow is in a single procedure. This makes the navigation much more readable, as a console application. But WASH is not continuation based, but log based, and the log was stored in the client, that means that it was also restful to a certain level. That approach solved the big problems of memory usage and serialization of continuation based frameworks. It also solved the problem of form safety before the development of formlets and the widespread of applicative functors. But I do not pretend to resucitate WASH. I just miss a continuation of this line of work , but this was not the case. I took a deeper look at WASH after developping MFlow, years after the discontinuation of WASH. MFlow coincidentally, is log based in a different way. I supposed that it was based on continuations, and I didn't like them, but it was not. If the project would have been prosecuted, who knows...It had a edge over other web developments in other languages, but it was hard to understand, just because the approach was original and unique. I consider MFlow as a continuation of WASH in "philosophical" terms. 2013/5/6 Tom Ellis <tom-lists-haskell-cafe-2013(a)jaguarpaw.co.uk> > On Sun, May 05, 2013 at 10:46:23PM +0200, Alberto G. Corona wrote: > > The case of WASH is a pity. Architecturally It was more advanced that > many > > recent haskell web frameworks. The package would have been a success > with > > little changes in the DSL syntax. > > Could you briefly summarise the difference between WASH's approach and that > of the more recent frameworks? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Alberto.

1 0

A three page web application in a tweet (in Haskell)
by Alberto G. Corona 03 May '13

03 May '13

Hi, Just to share my excitement with you: https://twitter.com/AGoCorona/status/329648864082677760 See the link in the tweet for an explanation Best Regards, -- Alberto.

1 0