[grapefruit] [reactive] FRP + physics / status of hpysics

[Daniel Bünzli]

Le 6 mars 09 à 17:57, Wolfgang Jeltsch a écrit :

> However, my e-mail also reached the Grapefruit mailing list (but  
> Daniel Bünzli’s didn’t) and the
> version there has the correct address in its To: headers.

Btw. the one for haskell-cafe didn't either, I guess you must be  
subscribed to post there.

> What I want to say is that coming up with a signal implementation  
> that allows
> Haskell recursion and has other advantages at the same time is a big
> challenge.

I understand this is a tough problem. I cannot help here, my own frp  
implementation is impure -- which brings in other problems -- and  
despite this I also did put some limitations in recursive definitions.

> I suppose that most of the recursive definitions you would use in  
> FRP are differential or integral equations.

Not necessarly, for example for UIs it is common to feedback the  
result of the ui interaction to the ui itself until a particular  
condition is met.

> By the way, continuous signals don’t have steps. These are just  
> introduced by sampling.

Ok so replace "step" by "dt", where "dt" is an infinitesimal delay.

> “State machine” sounds like a discrete problem. You can use  
> accumulation over event sequences here (as, for example, provided by  
> the scan function in FRP.Grapefruit.Signal.Discrete).

Maybe the wording "state machine" was too restrictive, the problem is  
when you want the argument "DSignal era val" of scan to be the result  
of scan "DSignal era accu" itself, higher order state machines.

Maybe you can work around the recursive behaviour issue by providing  
special combinators, I don't want to argue that. It's just that I see  
recursion occuring naturally in systems and recursion is the natural  
way of expressing things in FP. This is why I'd prefer a system that  
allows me to write directly such definitions.

(actually the gist of my message was more about the physics than about  
the recursion issue)

Best,

Daniel