I’m glad you’re starting by asking about a specification rather than implementation first.
There are a lot of ideas floating around about what FRP is.
From the very start in the early 90’s (when I was working in interactive graphics at Sun Microsystems and then Microsoft Research), it has been about two properties (a) denotative and (b) temporally continuous.
Many folks drop both of these properties and identify FRP with various implementation notions, all of which are beside the point in my perspective.
To reduce confusion, I would like to see the term “functional reactive programming” replaced by the more accurate & descriptive “denotative, continuous-time programming” (DCTP), as suggested by Jake McArthur in a conversation last year.
By “denotative”, I mean founded on a precise, simple, implementation-independent, compositional semantics that exactly specifies the meaning of each type and building block.
The compositional nature of the semantics then determines the meaning of all type-correct combinations of the building blocks.
For me, denotative is the heart & essence of functional programming, and is what enables precise & tractable reasoning and thus a foundation for correctness, derivation, and optimization.
Peter Landin recommended “denotative” as a substantive replacement to the fuzzier term “functional” and a way to distinguish deeply/genuinely functional programming from merely functional-looking notations.
See this comment for some Landin quotes and a paper reference.
About continuous time, see the post Why program with continuous time? and my quote in AshleyF’s answer on this page.
I’m surprised over & over by hearing the claim that the idea of continuous time is somehow unnatural or impossible to implement, considering the discrete nature of computers.
This line of thinking strikes me as bizarre, especially when coming from Haskellers, for a few reasons:
- Using lazy functional languages, we casually program with infinite data on finite machines. We get lovely modularity as a result, as illustrated in John Hughes’s classic paper Why Functional Programming Matters.
- There are many examples of programming in continuous space, for instance, vector graphics, but also things like Pan.
- I like my programs to reflect how I think about the problem space rather than the machine that executes the programs, and I tend to expect other high-level language programmers to share that preference.
(“A programming language is low level when its programs require attention to the irrelevant.” – Alan Perlis)
I’ve been making libraries for programming with continuous time since TBAG and ActiveVRML (the first DCTP/FRP system) and later Fran.
It’s easy to implement correctly.
A few different approaches are described in the paper Functional Implementations of Continuous Modeled Animation.
Implementing continuous time efficiently (and still correctly!) is another matter, especially avoidance of recomputing unchanging values.
(See the paper Push-pull functional reactive programming.)
For related remarks, please see my answer to The difference between Reactive and Functional-Reactive programming and to What is (functional) reactive programming? Update: For more on why continuous time matters, see these notes. Update: See also, my 2015 talk The essence and origins of FRP (and the related talks linked there).
Good luck with your exploration, and please let me know if you have any questions.
My contact info is on my home page.