[Haskell-beginners] FRP

[Heinrich Apfelmus]

Dear Miguel,

sorry for the late reply, I have been traveling in the last weeks.

Miguel Negrao wrote:
> Heinrich Apfelmus escreveu:
>> Miguel Negrao wrote:
>>> Thanks for the explanation. I was wondering, how would one translate
>>> this Yampa code into reactive-banana:
>>>
>>> fallingBall :: Pos -> Vel -> SF () (Pos, Vel)
>>> 	fallingBall y0 v0 = proc () -> do
>>> 		v <- (v0 +) ˆ<< integral -< -9.81
>>> 		y <- (y0 +) ˆ<< integral -< v
>>> 		returnA -< (y, v)
>>> fallingBall’ :: Pos -> Vel -> SF () ((Pos,Vel), Event (Pos,Vel))
>>> fallingBall’ y0 v0 = proc () -> do
>>> 	yv@(y, _) <- fallingBall y0 v0 -< ()
>>> 	hit <- edge -< y <= 0
>>> 	returnA -< (yv, hit ‘tag‘ yv)
>>> bouncingBall :: Pos -> SF () (Pos, Vel)
>>> bouncingBall y0 = bbAux y0 0.0
>>> 	where
>>> 		bbAux y0 v0 = switch (fallingBall’ y0 v0) $ \(y,v) -> bbAux y (-v)
>>
>> [...]
> 
> Yes, looking at the internals of Yampa I had seen that they have
> internal time management, but my question was more specifically if there
> was a way to have a function like bbAux which recursively switches into
> itself. Would it be possible with the new dynamic switching ? I find
> that way of expressing the discontinuous changes quite elegant.

Yes, it's possible, but it will feel alien. There are two reasons for that:

1. switchB  is meant to change the behavior whenever the event occurs, 
not just on the first occurrence. The  bbAux  function is recursive 
precisely because only the first occurrence causes a switch in Yampa. 
Maybe  reactive-banana  should adopt this approach as well, but I'm 
undecided.

2. In Yampa,  fallingBall  is a signal function, which means that it has 
no fixed starting time. In contrast, behaviors in reactive-banana 
usually have a fixed starting time so that they can accumulate state. Of 
course, reactive-banana also has behaviors that have a variable starting 
time, but they are a separate type. In other words, you have to model it as

     fallingBall :: Pos -> Vel -> AnyMoment Behavior Pos


So, modeling this using dynamic event switching is possible, but these 
two points mean that it's probably much easier to use a recursive 
event/behavior combination like in the  Animation.hs  example or Andreas 
Bernstein's breakout code.

As you can see, dynamic event switching is still uncharted territory, 
there are a lot of design patterns to discover.


> Even
> more elegant seems to be the instantaneous impulses (modeling of
> distributions or dirac deltas) although I couldn’t find any functioning
> code that implements it [1].

Well, I do not think that mixing continuous signals and discrete events 
in this way is a good idea. Having two separate types gives you more 
information to reason with: Event can only be discrete, Behavior can 
only be continuous.


I would like to stress again that the design space for FRP is huge, 
which is good. But the ultimate goal is to simplify a certain class of 
code, namely GUIs, audio and games, and I feel that few, if any FRP 
approaches have been tested enough against these "hard" targets. I mean, 
if I use FRP to implement a game and the code is just as messy as the 
imperative version, then I may wonder why I am doing this at all. So 
far, I only know of Conal who makes a convincing argument for his style

   Conal Elliott. Declarative Event-Oriented Programming.
   http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.1064

(Interestingly, he doesn't really use dynamic event switching in this 
instance.)

Simplicity also hinges on a lot of details, see for instance my 
discussion on GUI elements

http://apfelmus.nfshost.com/blog/2012/03/29-frp-three-principles-bidirectional-gui.html

Conal's decision to allow recursion between Event and Behavior is one of 
these very important details.


Best regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com