On Aug 8, 2007, at 3:14 PM, Peter Verswyvelen wrote:

So could you please tell me more about the problem with pure functional GUIs and why this is not part of the Haskell library? I mean a GUI library completely written in Haskell, not wrapping a popular library.

I had quite a lot of experience in pure functional GUI technology in developing the user-interface for the ICAD system -- a domain specific language for mechanical engineering. We developed another domain specific language for describing user-interface objects as a tree structure and implemented commands as applicative transactions using Zippers, though we called them path transactions. (Oh, did I mention this was in 1987?) Redisplay and undo of course were handled automatically. It was developed on Lisp Machines and then ported to X-Windows. I believe there are some nooks and crannies in the aircraft industry were it is still being used. There were some issues which time may have solved. 1.) Redisplay could be a little tedious due to slow video hardware. 2.) Locality became a problem with the shared data-structures being spread throughout memory. Thus performance could be adversely affected by paging. (In 1987, 8MBytes of Lisp Machine memory cost $10,000.) Issues that time won't solve. 1.) It was non-standard -- at the time that meant "not Motif." Does anybody remember Motif? 2.) It is a thankless task. Innovation is not welcomed. It's better left up to committees. I don't believe that there is any technical reason why something interesting couldn't be done. But if you actually want people to use your GUI tools, that is several orders of magnitude more work -- and not the most interesting kind. An interesting possibility that arises when coding has become so effortless as it now has in Haskell, is to create GUI technologies just for a single project. Encourage innovation and experimentation in usability with a captive audience. An example of this is the PureData computer music system. The user-interface is quite innovative and non-standard, but the users of the application have taken it to a cult status even though it's purposefully kind of ugly. http://puredata.info/ ___________________ (---o-------o-o-o---o-o-o----( David F. Place mailto:d@vidplace.com

Hello Peter, Wednesday, August 8, 2007, 11:14:37 PM, you wrote:

To me, having an imperative background, a graphical application is just a big tree of data that evolves when events from the OS come in. (this data is NOT per se the data for the GUI element; instead use the model-view-controller design pattern) In Haskell, instead of mutating the data (as done in C/C++), a infinite stream of this tree-data is generated responding to an infinite steam of events, as in Paul's SOE book (the reactive stuff). Since most of the data can be shared, the performance impact should be minimal.

So could you please tell me more about the problem with pure functional GUIs

seems that such program will have no effects :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com