What's the difference between Behavior and Event in FRP?

Question

I'm currently reading the documentation of WebSharper. In the section about FRP, it states:

Functional Reactive Programming (FRP) typically provides an Event type for event streams and a Behavior type for time-varying values, together with useful combinators on those.

...

However, for now we decided to avoid implementing FRP. Instead, we focus on a subset of functionality, defining time-varying View values similar to Behaviors, but without support for real-time sampling. Event streams are left for the user to tackle using callbacks or third-party libraries. This is a vast simplification over FRP and is much easier to implement efficiently.

As weak pointers become available in JavaScirpt, this decision might be revised, especially in light of OCaml React success.

In the more immediate future, we intend to provide Concurrent ML combinators to better support dealing with event streams and improve composition of Components.

However, I'm not sure what exactly is the difference between "Event type" and "Behavior type" described here. I Googled some articles/tutorials, but they don't seem to be very explicit on this either.

I'm not sure what I am missing out by not having "Event" in WebSharper's implementation.

Sorry if this question sounds fundamental. I'm not familiar with concepts related to FRP.

--

EDIT: I think I found the answer to my doubt on what is amiss without event streams, at FRP - Event streams and Signals - what is lost in using just signals?. The main points are:

1. event streams allow for accumulative updates, while behaviors can only depend on the current value of the observed elements.

2. if event and behavior are both implemented, they allow for recursion within the system.

Haynes

Answer 1

The distinction between events and behaviours is something that dates back to the first paper on Functional Reactive Animations (PDF), which explains the distinction quite nicely. The idea is that:

• Behaviours represent values that change in time - for example, mouse X coordinate varies in time, but it always has some value.

• Events represent discrete events in the system - they happen every now and then and can trigger some change, but do not always have a value. For example, mouse click can happen, but you cannot ask "what's the current value of click".

These are very nice as theoretical ideas, because you can do different things with behaviours and events and they nicely capture some intuition behind different kinds of things in reactive systems.

In practice though, it is quite tricky to implement - most representations of "behaviours" end up using sampling, so they behave much like discrete events (maybe because that's how computers work?) and so only a few systems actually follow the original strict distinction.

Ritz

Thanks for the answer. Though in this particular case, I'd still like to know a bit more in detail, what is the WebSharper team trying to say here? If events are discrete, then how come the inability for real-time sampling hinders that? And what does "event streams" refer to? What do I miss if I use their implementation compared with others'? Knowing the theoretical difference, I'm still unable to decipher their post, unfortunately... – Haynes

I think what they are saying is that they do not make explicit distinction between the two kinds. But I'm not familiar with WebSharper, so I'm not sure. Sorry! – Ritz

Actually I think I found the explanation here: #22989753 There seems to be two things. 1. event streams allow for accumulative updates while behaviors can only depend on the current value of the observed elements. 2. if event and behavior are both implemented, they allow for recursion within the system. – Haynes

By the way, may I know what do you normally use to do web development with F#, if you don't use WebSharper? Some more fundamental frameworks/building blocks? – Haynes

@TomasPetricek Having implemented an FRP library myself, reactive-banana, I would say that Behaviors work nicely as practical ideas as well. :-) Note that their utility is not tied to whether they can change continuously or only at discrete time steps. – Mendel