On Nov 21, 2007 3:49 AM, Laurent Deniau <<a href="mailto:laurent.deniau@cern.ch">laurent.deniau@cern.ch</a>> wrote:<br><br>> Peter Verswyvelen wrote:<br>> > Conal Elliott wrote:<br>> >> Moreover, functional programming makes it easy to have much more state
<br>> >> than imperative programming, namely state over *continuous* time. The<br>> >> temporally discrete time imposed by the imperative model is pretty<br>> >> puny in comparison. Continuous (or "resolution-independent") time has
<br>> >> the same advantages as continuous space: resource-adaptive, scalable,<br>> >> transformable.<br>> > Yes, that's true, but isn't that also the problem with FRP? I mean, most<br>> > of the papers I'm reading about (A)FRP indicate that no matter how nice
<br>> > it is to have the continuous time model<br><br>> I agree with Conal, it's not a continuous time model but a<br>> resolution-independent time model. <br><br>What do mean by resolution-independent vs continuous?
<br><br>I meant them more-or-less synonymously. Semantically, there's no notion of resolution. When it's time to introduce a resolution for discrete rendering, there's no resolution imposed by the model.<br>
<br>> The reason it that Arrows (like<br>> Monads) encapsulate the sequence of transitions. Unless the time is a<br>> parameter of the transition, it is independent of the time (resolution),
<br>> but still captures its ordered nature.<br><br>I'm confused again. I don't think of Arrow as implying transitions at all.<br><br>> > to get fine grained control<br>> > over execution times and resources, one needs to fall back to the
<br>> > discrete delta-time approach?<br><br>> If you need synchronization, yes.<br><br>Why? What about synchronization implies discretness in the model?<br><br> - Conal<br><br>