> 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"?

Note, you don't get any signal here, we are talking about an _event_.
So the sequence of event occurences you will see is 'p', 'r', 'o',
'g', 'r', 'a', 'm', 'm', 'i', 'n', 'g'. Now if you fold over these
occurences as I suggested to make a string signal, the sequence of
changes in the signal you will see is "", "p", "pr", "pro", "prog",
"progr", "progra", "program", "programm", "programmi", "programmin",
"programming" (you could have chosen a shorter word, that was painful
to write).

> 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.

I'm not sure but maybe your problem is just a terminology thing.
Because in frp what is called an event confusignly represents many
events, it represents event occurences of a kind of event (e.g. the
keystrokes of a keyboard).

So the function time -> 'a option returns a value if there's an
occurence of the event at that time (e.g. if the
user pressed a key at that time) and None otherwise.

> 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?

I wouldn't say it "depends", it makes you believe, that's the way you
should think about when you program. But in the programming world
everything is eventually discrete and your primitive input is giving
the pace. Have a read at the section "Continuity" there :

http://erratique.ch/software/react/doc/React#sigsem

Best,

Daniel