[Haskell-cafe] Tetris

[Laurent Deniau]

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.