Interesting. Thanks for the reply. It might be nice to have some performance benchmarks for all these experimental systems, so we can compare them. I could understand that performance might be an issue for games, but for GUIs? I mean many imperative GUI systems use rather slow message dispatching systems, and we use those every day. Look at the new Windows Presentation Foundation system found in VISTA. Here events are broadcasted and routed through the whole element tree. This is also rather slow I guess.
-----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe- bounces@haskell.org] On Behalf Of Wolfgang Jeltsch Sent: Thursday, February 07, 2008 12:25 PM To: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available
Hello Peter,
an answer to an “old” e-mail (from January 25). Sorry for not answering earlier.
Am Freitag, 25. Januar 2008 00:23 schrieben Sie:
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?
Performance problems and lack of widgets are the two things that come to my mind immediately. Maybe also lack of a good way of doing dynamic user interfaces (user interfaces with a changing set/order of widgets).
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 think, performance is a big problem. To me it seems that Yampa-based GUIs maybe have a performance penalty of more than just a constant factor. Please have a look at the sections “Implementation and efficiency” and “Signals” under http://haskell.org/haskellwiki/Talk:Grapefruit.
[…]
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...)
Not necessarily a bug. There are events which don’t result in changes of the GUI, for example, mouse clicks into empty areas.
[…]
Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.21/1263 - Release Date: 2/6/2008 8:14 PM