<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">Wolfgang Jeltsch wrote:</font>
<blockquote cite="mid:200801241256.46959.g9ks157k@acme.softbase.org"
 type="cite">
  <pre wrap=""><font face="Helvetica, Arial, sans-serif">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).
</font></pre>
</blockquote>
<font face="Helvetica, Arial, sans-serif">Could you elaborate a bit on
that? What are the current obstacles to be solved? <br>
<br>
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.<br>
<br>
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 </font><font
 face="Helvetica, Arial, sans-serif">routing and </font><font
 face="Helvetica, Arial, sans-serif">checking which event happened. <br>
<br>
Warning to newbies: the above is most likely incorrect information,
this is just the way I experienced it <span class="moz-smiley-s3"><span>
;-) </span></span><br>
<br>
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) <span class="moz-smiley-s3"><span> ;-) </span></span>).
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...<br>
<br>
</font>
<blockquote cite="mid:200801241256.46959.g9ks157k@acme.softbase.org"
 type="cite">
  <pre wrap=""><font face="Helvetica, Arial, sans-serif"><span
 class="moz-smiley-s1"><span> :-) </span></span>The working name for Grapefruit was Vegetables, by the way. ;-) </font></pre>
</blockquote>
<font face="Helvetica, Arial, sans-serif">LOL! I'll certainly look at
it, I find it very fascinating (though confusing...) to compare all
existing reactive solutions<br>
</font><font face="Helvetica, Arial, sans-serif"><br>
Thank you,<br>
Peter<br>
<br>
</font>
</body>
</html>