I think the problem in this case is the infamous recursive integral one... Position of the ball depends on the velocity and vice versa. I'm not sure if it is possible to do right now with Reactive. That's why pong is still number one on my list of test cases for any reactive library :-) Or actually a breakout game is even better, since it involves dynamic collections.


On Wed, Mar 4, 2009 at 9:39 PM, Patai Gergely <patai_gergely@fastmail.fm> wrote:
> I would model this as the position being the integral of the ball's
> velocity, and switch the velocity, this way, you don't need to do
> complicated things with trying to grab the position from the last
> section of the behavior.
I tried that too, but the result was the same. I don't see how that
would help anyway, since integral is just a stepper over an accumE. I
even tried a function-valued behaviour that had to be supplied time
explicitly, which did move at least, but still <<loop>>-ed, so it never
switched.

> Re delayed switching, Reactive already has a kind of delayed
> switching, that happens automatically when necessary.  If you attempt
> to take the value of a Reactive value at the exact moment of a switch,
> you will receive the value from the previous step.
Oh yes, now I went back to the 'Simply efficient...' paper, and it says
so indeed. I just misunderstood that part (off by one thinking, as
always ;). However, the problem still remains, because it's not only the
new value that depends on the current one but the time of switching as
well. This knot is apparently too tight for the time being.

Gergely

--
http://www.fastmail.fm - The professional email service

_______________________________________________
Reactive mailing list
Reactive@haskell.org
http://www.haskell.org/mailman/listinfo/reactive