[Haskell-cafe] Draft chapters of "Real World Haskell" now publicly available

[Peter Verswyvelen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20080125/59e6af57/attachment.htm