Afaik, you&#39;re right about Yampa not being event-driven.&nbsp; I&#39;ve been working on alternatives for a while that are event-driven while still genuinely functional (non-IO).&nbsp; See <a href="http://haskell.org/haskellwiki/Reactive">
http://haskell.org/haskellwiki/Reactive</a> and <a href="http://haskell.org/haskellwiki/TV">http://haskell.org/haskellwiki/TV</a> .&nbsp; I have some blog posts in the works about the inner goings-on of Reactive.<br><br>&nbsp; - Conal
<br><br><div class="gmail_quote">2008/1/24 Peter Verswyvelen &lt;<a href="mailto:bf3@telenet.be">bf3@telenet.be</a>&gt;:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">



  

<div bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">[...]</font><font face="Helvetica, Arial, sans-serif"><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 &quot;pulls&quot; 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><span>
;-) </span></span><br></font></div></blockquote></div><br>