It seems to be a trend to use more and more IO in new FRP approaches.<div><br></div><div>Grapefruit&#39;s circuits encapsulate side effects, as does your approach</div><div><br></div><div>This is a big departure from the &quot;pure&quot; libs like Fran, Yampa, Reactive, ...</div>
<div><br></div><div>I wander if this is because of some fundamental problem with functional programming when it comes to FRP?†</div><div><br></div><div>Some people claim that IO is also pure, and I tend to agree if we can capture the state of the real world and rewind to it somehow :)</div>
<div><br></div><div><div class="gmail_quote">On Thu, Apr 2, 2009 at 4:06 PM, Jeff Heard <span dir="ltr">&lt;<a href="mailto:jefferson.r.heard@gmail.com">jefferson.r.heard@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Check links... †god. †<a href="http://vis.renci.org/jeff/buster" target="_blank">http://vis.renci.org/jeff/buster</a> †(can you tell<br>
I was up till 3am last night?)<br>
<div><div></div><div class="h5"><br>
On Thu, Apr 2, 2009 at 10:05 AM, Jeff Heard &lt;<a href="mailto:jefferson.r.heard@gmail.com">jefferson.r.heard@gmail.com</a>&gt; wrote:<br>
&gt; Yes,sorry. †vis, not vs. <a href="http://vis.renci.org/buster" target="_blank">http://vis.renci.org/buster</a><br>
&gt;<br>
&gt; It is a bit like grapefruit&#39;s circuits, but where Grapefruit circuits<br>
&gt; describe the flow of events from place to place, Buster never does.<br>
&gt; Events exist for all behaviours, to be selected by name, group, or<br>
&gt; source. †The other major difference is the |~| or &quot;beside&quot; operator,<br>
&gt; which describes concurrent application of behaviours.<br>
&gt;<br>
&gt; A last but somewhat minor thing is that the Event type is fairly<br>
&gt; general, allowing for multiple data to be attached to a single event<br>
&gt; and this data to be of many of the standard types (Int, String,<br>
&gt; Double, ByteString, etc) as well as a user-defined type. †Of course,<br>
&gt; such an event type could be defined for other FRP frameworks as well.<br>
&gt;<br>
&gt; -- Jeff<br>
&gt;<br>
&gt; On Thu, Apr 2, 2009 at 9:53 AM, minh thu &lt;<a href="mailto:noteed@gmail.com">noteed@gmail.com</a>&gt; wrote:<br>
&gt;&gt; It&#39;s vis instead of vs:<br>
&gt;&gt; <a href="http://vis.renci.org/jeff/buster/" target="_blank">http://vis.renci.org/jeff/buster/</a><br>
&gt;&gt;<br>
&gt;&gt; 2009/4/2 Peter Verswyvelen &lt;<a href="mailto:bugfact@gmail.com">bugfact@gmail.com</a>&gt;:<br>
&gt;&gt;&gt; Sounds vaguely like Grapefruit&#39;s circuits, but I could be very wrong...<br>
&gt;&gt;&gt; The link you provided seems to be broken?<br>
&gt;&gt;&gt; On Thu, Apr 2, 2009 at 3:05 PM, Jeff Heard &lt;<a href="mailto:jefferson.r.heard@gmail.com">jefferson.r.heard@gmail.com</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Read more about it on its webpage: <a href="http://vs.renci.org/jeff/buster" target="_blank">http://vs.renci.org/jeff/buster</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Yes, itís to solve a particular problem. †And yes, this is a rough<br>
&gt;&gt;&gt;&gt; draft of an explanation of how it works. †Iíve not even really<br>
&gt;&gt;&gt;&gt; solidified the vocabulary yet, but I have this module which couches a<br>
&gt;&gt;&gt;&gt; large, abstract, interactive (both with the user and the system),<br>
&gt;&gt;&gt;&gt; multicomponent application in terms of a bus, inputs, behaviours, and<br>
&gt;&gt;&gt;&gt; events.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; † †* Time is continuous and infinite.<br>
&gt;&gt;&gt;&gt; † †* An event is a static, discrete item associated with a particular<br>
&gt;&gt;&gt;&gt; time.<br>
&gt;&gt;&gt;&gt; † †* The bus is the discrete view of event in time at an instant.<br>
&gt;&gt;&gt;&gt; † †* A widget is an IO action that assigns events to a particular<br>
&gt;&gt;&gt;&gt; time based only upon sampling the outside world (other events and<br>
&gt;&gt;&gt;&gt; behaviours are irrelevant to it). †e.g. a Gtk Button is a widget, a<br>
&gt;&gt;&gt;&gt; readable network socket is an widget, the mouse is an widget, the<br>
&gt;&gt;&gt;&gt; keyboard is an widget, a multitouch gesture engine is a widget.<br>
&gt;&gt;&gt;&gt; † †* A behaviour is a continuous item ó it exists for the entire<br>
&gt;&gt;&gt;&gt; program and for all times ó which maps events on the bus to other<br>
&gt;&gt;&gt;&gt; events on the bus. †It is an IO action as well ó where widgets only<br>
&gt;&gt;&gt;&gt; sample the outside world and are in a sense read only, behaviours<br>
&gt;&gt;&gt;&gt; encapsulate reading and writing.<br>
&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; Haskell-Cafe mailing list<br>
&gt;&gt;&gt;&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt;&gt;&gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; Haskell-Cafe mailing list<br>
&gt;&gt;&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt;&gt;&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div>