Re: more on frp (was Re: [Caml-list] Re: Recursion on React.events)

[Aaron Bohannon <bohannon@seas.upenn.edu>]

On Wed, Dec 9, 2009 at 11:43 AM, Daniel Bünzli
<daniel.buenzli@erratique.ch> wrote:
>> Personally I've yet to read any comprehensible introduction to FRP.

> In fact events and signals are duals. One can be implemented in terms
> of the other (signals can be seen as the event occurences of its value changes),
> However it makes sense to keep the two concepts separate (code
> clarity, efficiency issues, semantic details with comparison).

> Suppose we want to remember the last keysym that was issued. That's a
> signal, it is defined at any point in time. For that the S.hold
> combinator can be used, it remembers the last occurence of an event :
>
>  let last_keysym = S.hold null_keysym keydown
>
> Each time keydown gets an occurence S.hold updates the signal with the
> new occurence value. null_keysym is used to initalize the signal (it
> needs a value at the time it is created and the keydown event may not
> give us one at that time).
>
> Now we would like to concatenate the stream of keychar occurences into
> a string.

Your example perfectly illustrates what makes understanding FRP hard:
when I type the string "programming", should I expect to get a signal
with a value of "programming" or "programing"?

Signals without events have an semantics that seems straightforward
(to me).  But I have very little intuition for events, as represented
by a type such as "time -> 'a option", and their conversion to and
from signals.

Also, I like the idea of making different choices for what "time" is,
but doesn't the semantics of FRP depend on time being continuous?

 - Aaron