Wolfgang Jeltsch wrote: 
Indeed.  A functional approach to GUIs is nice but at the moment we don’t have 
anything that is suitable for solving real world problems (although this is 
being worked on).
Could you elaborate a bit on that? What are the current obstacles to be solved?

When I looked at Yampa, I didn't really see a problem with making a GUI or interactive application based on it (besides maybe performance and space/time leaks, the latter IMO being a general problem in Haskell that just occurs quicker in reactive programming). I could model state machines, dynamic collections, events and event handlers with it, all hierarchically. I just would have to practice much much more to get good at it. Of course, I'm way too new to functional programming to really judge Yampa, it's just the feeling I got from it.

The main problem I could see is that Yampa is not really event driven in the imperative sense; I mean in an ideal event based system, the hardware triggers an interrupt when some sensor changes, and this then triggers other software events; only the code that is related to handling the event that occurred is executed. But the event that is handled could potentially not be needed for the current output (which could be considered as a programming bug...) I think Yampa does not do that, it kinda "pulls" the information out of the current signal function network, which has the advantage of only executing the code that is needed for the output, but the disadvantage is that it does a lot of routing and checking which event happened.

Warning to newbies: the above is most likely incorrect information, this is just the way I experienced it ;-)

Now IMO the OO way of handling GUIs is also not carved in stone. OO and imperative programmers also seem to continue the search for "the best" GUI event system. For example, the first version of  the .NET GUI "borrowed" the Delphi approach, which was a direct link (through a delegate in .NET, called closure in Delphi) between the event source and the event listener (in C we know that as a list of (callback,userdata)  ;-) ). Same for QT's signal/slot system. Other systems use a producer/dispatcher/consumer pattern (or how is it called). Java AWT initially used a message based system, then switched to an interface based system. Other systems (like MFC) used a message based approach, where the message is routed to many components in a hierarchy. The latest version of .NET's GUI system (WPF) again uses such an "element tree" and the event can be routed through the whole tree in both directions. Some claim Smalltalk's model-view-controller is still the best pattern, others claim that the controller is too closely linked to the view to be really separate and stick to a document/view model, or just duplicate data by using some kind of data-binding... I tried all approaches over the last 20 years, and I still see no "best" way...

 
 :-) The working name for Grapefruit was Vegetables, by the way. ;-)
LOL! I'll certainly look at it, I find it very fascinating (though confusing...) to compare all existing reactive solutions

Thank you,
Peter