[Haskell-cafe] Is this a correct explanation of FRP?
Heinrich Apfelmus
apfelmus at quantentunnel.de
Fri Mar 30 14:28:30 CEST 2012
Peter Minten wrote:
>
> I've been trying to get my head around Functional Reactive Programming
> by writing a basic explanation of it, following the logic that
> explaining something is the best way to understand it.
>
> Am I on the right track with this explanation?
I think so. Your explanation looks fine to me, except for one really
subtle but really important issue:
> Stepped sounds a lot like stepper and we can create that function by
> making a few small adjustments.
>
> type Time = Int
> stepper :: a -> [(Time, a)] -> (Time -> a)
> stepper d es = \t -> case takeWhile (\(t', _) -> t' <= t) es of
> [] -> d
> xs -> snd (last xs)
The correct definition of stepper uses < instead of <=
... case takeWhile (\(t', _) -> t' < t) es of ...
In other words, at the moment t == t' , the behavior still returns the
"old" value, not the "new" value from the event. This important because
it allows for recursive definitions, like
let b = accumB 1 e
e = (+) <$> b <@ eKey
If you were to use <= here, then the new value of the behavior would
depend on itself and the result would be undefined.
(Actually, even if you use the correct definition for stepper, trying
to implement Event and Behavior in terms of [(Time,a)] and Time -> a
in Haskell would give undefined on this recursive example. That's
because the data types still aren't lazy enough, you have to use another
model. That's one reason why implementing FRP has traditionally been hard.)
> P.S. Sorry about the long mail, the explanation ended up a little longer
> than I originally expected. :)
I know it was time to get a blog when my mailing list posts got too long. ;)
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
More information about the Haskell-Cafe
mailing list