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.

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.