Peter Verswyvelen wrote:
Laurent Deniau wrote:
Peter Verswyvelen wrote:
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.
I'm currently reading "FRP, Continued". Maybe I got confused by the text
on page 56, which introduces a delay (noEvent --> addOrDelCTs) to avoid
an infinite loop.
I haven't read (yet) the paper (so take my remark with care), but
looking roughly at this function, it seems that it tries to avoid
infinite loop by introducing a delay (noEvent). This is like tail in a
stream-based Fibonacci. You need to delay (or shift for a stream) input1
vs input2 because input2 is the output of the the current
step/transition, otherwise you get an infinite loop. This is because of
the recursive nature of what the transition needs to do (the generator),
not with the time.
An analogy of FRP in the OO world is the Event-based loop. If an event
queues another event which itself (re)queue the current event, you'll
get an infinite loop (or more probable a deadlock ;-) as well (in
CPS-based FRP, the chain of continuations becomes infinite).
I would say that conceptually (may be wrong in this particular case),
this happens because you do not respect the principle of causality, that
is you're looking at the future. This is a common pattern in adaptive
theory where memory is delays. In that case you never look at the
future, you can only estimate it (in the case of predictive model).
Nevertheless, I think that AFRP and Signal match very well adaptive
theory (signal processing or control theory). If I were good enough in
Haskell (and had the time to do it, sic!), I would give a try to build
adaptive systems on top of Yampa. The problem is that for efficiency
reason one needs to mix Signals with things like Fast Arrays where
arrays on the lhs are mutables but becomes immutable once on the rhs. I
dream of a lib doing efficient signal processing on top of these two ideas.
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.
Yes that is a very interesting paper, but since I'm still trying to
understand and use Yampa, I will have to re-read the paper. It would be
nice if Paul Hudak wrote a "Haskell HIGH School of Expression" book,
explaining Yampa, because I really enjoyed the SOE book.
I agree!
a+, ld.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
