Peter Verswyvelen wrote:
Conal Elliott wrote:
Moreover, functional programming makes it easy to have much more state
than imperative programming, namely state over *continuous* time. The
temporally discrete time imposed by the imperative model is pretty
puny in comparison. Continuous (or "resolution-independent") time has
the same advantages as continuous space: resource-adaptive, scalable,
transformable.
Yes, that's true, but isn't that also the problem with FRP? I mean, most
of the papers I'm reading about (A)FRP indicate that no matter how nice
it is to have the continuous time model
I agree with Conal, it's not a continuous time model but a
resolution-independent time model. The reason it that Arrows (like
Monads) encapsulate the sequence of transitions. Unless the time is a
parameter of the transition, it is independent of the time (resolution),
but still captures its ordered nature.
to get fine grained control
over execution times and resources, one needs to fall back to the
discrete delta-time approach?
If you need synchronization, yes.
And you still need to think about where
you have to introduce delays to avoid infinite loops?
I don't see why, unless you want to have a memory or explicitly stop the
time which means it's a parameter of the transition as mention above
(but instantaneous transitions seems strange). So, the causality of the
transitions with a discrete time should not lead to infinite loops. The
time delay exists de facto.
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?
I missed your question, but it's an interesting question. I found very
interesting and instructive the paper of Hai Liu and Paul Hudak on the
problem of space leaks in FRP.
a+, ld.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
