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