Hi Peter, &gt;&nbsp;&nbsp;&nbsp;&nbsp; First of all Conal, I find all of your work amazingly cool. Do you have fan list? ;-) :) &gt;&nbsp;&nbsp;&nbsp;&nbsp; Conal Elliott wrote: &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Moreover, functional programming makes it easy to have much more state than imperative programming, namely state over *continuous* time.&nbsp; The temporally discrete time imposed by the imperative model is pretty puny in comparison.&nbsp; Continuous (or &quot;resolution-independent&quot;) time has the same advantages as continuous space: resource-adaptive, scalable, transformable.

<br>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Yes, that&#39;s true, but isn&#39;t that also the problem with FRP? I mean, most of the papers I&#39;m reading about (A)FRP indicate that no matter how nice it is to have the continuous time model, to get fine grained control over execution times and resources, one needs to fall back to the discrete delta-time approach? 

<br><br>I haven&#39;t found that to be the case.&nbsp; I&#39;d like to understand what specific implementation issues seem to conflict with continuous time.&nbsp; Can anyone help me out?<br><br>&gt; And you still need to think about where you have to introduce delays to avoid infinite loops? I might be wrong, since I don&#39;t understand everything in these papers yet ;-)

<br><br>There were two places in Fran where timing was a bit delicate to get termination.&nbsp; I made sure that reactive behaviors don&#39;t change at the moment of the event occurrence, but rather immediately after it.&nbsp; You could call it an &quot;infinitessimal delay&quot;.&nbsp; There was no delta&gt;0.&nbsp; The other is very similar: ordinary differential equations (expressed recursively, using integration).&nbsp; Again, there was no time delta in the semantics. &nbsp;

<br><br>I also got the impression that some of the folks at Yale thought it necessary to add in some kind of (non-infinitessimal) delay, related to termination, but I don&#39;t know why.&nbsp; Maybe Henrik will comment.<br><br>

&gt;&nbsp;&nbsp;&nbsp;&nbsp; About continuous time; it is in fact, not really continuous is it, since floats are used to approximate time. So the longer your program runs, the less accurate an absolute time value will become no? Okay, if you use 64-bit floats, you will have to let is run a very long time :-)

Sure.&nbsp; And yes 64 bits help.&nbsp; And we could certainly use a bigfloat representation to get really continuous time (and space). &gt;&nbsp;&nbsp;&nbsp;&nbsp; Since nobody replied yet on my question about the future of (A)FRP, maybe I can ask it again here? What is the future for FRP? Are other approaches better suitable for reactive applications?

<br><br>I&#39;ve been itching to get back into (A)FRP to address some of these issues of continuous time, as well as modular interaction.&nbsp; Also toward making a much more efficient implementation, based mainly on data-driven evaluation.&nbsp; I&#39;ve made some preliminary experiments, described at 

<a href="http://haskell.org/haskellwiki/DataDriven">http://haskell.org/haskellwiki/DataDriven</a> , used in Phooey, GuiTV, and Eros.<br><br>Cheers,&nbsp; - Conal<br><br>