[reactive] Can we do without delayed switching?

[Thomas Davie]

On 4 Mar 2009, at 15:05, Patai Gergely wrote:

> Hi everyone,
>
> I feel this should be very simple to do, but I can't find a way to
> describe the movement of the ball in a breakout game. What do you  
> think,
> how should it be modelled?
>
> My idea was to define a vector-valued behaviour for the position of  
> the
> ball, and an event that fires on collisions and carries information
> about them. I believe such an event is necessary if I am to add  
> sound to
> the program, for instance, and it feels natural to me anyway. The ball
> position behaviour is then defined as a stepper in terms of this  
> event.
> Now the problem is that the event is defined in terms of the ball
> position among other things. At the moment this leads to a <<loop>>,  
> no
> matter how I try to approach the problem. This is not too surprising,
> since I can't really think of a way to define the event other than
> filtering some kind of clock tick (e.g. framePass) using whenE. Please
> tell me if there are other, fundamentally different alternatives.
>
> After thinking about this for a while, I feel that Reactive really  
> needs
> delayed semantics for switching, at least optionally. Otherwise I  
> don't
> see how we could possibly avoid looping, since the event must be
> generated assuming that the behaviour continues without switching.  
> Such
> an alternative reality doesn't fit in the semantic domain of time
> functions, but an infinitesimal delay looks like a possible solution
> that resolves the dependency loop. Using delayed constructs always  
> felt
> clumsy in Yampa too, but loops need special attention...
>
> Another thought I had for a moment was defining some kind of
> intermediate semantic domain, where behaviours are represented as a
> _list_ of time functions (with or without intervals provided), which
> would somehow give access to pre- and post-switching behaviours (like
> 'head' and 'tail') through some mid-level combinators. But I don't see
> how that could be made elegant on the application level, and it  
> doesn't
> seem to achieve anything the delayed switch can't do for us.
>
> What do you think?

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.

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.  This allows you to  
compute the new value even in a recursive computation, because  
sampling no longer gives you the value you are computing.

I hope that helps.

Thanks

Bob