I’m happy to announce the next version of reactive-banana. reactive-banana is a library for Functional Reactive Programming (FRP). FRP offers an elegant and concise way to express interactive programs such as graphical user interfaces, animations, computer music or robot controllers. It promises to avoid the spaghetti code that is all too common in traditional approaches to GUI programming.
(page 48)
A channel is an infinite stream of timestamped data values, or messages, each message denoting an event in the system. […]
type Channel a = [Event a]
data Event a = At Time a
(page 61)
In the semantics given in Chapter 5 every Ruth program is supplied with a tree of time values (or clock) as suggested in this paper and each Ruth process is given a different sub-tree of the clock […]
type Program = Clock -> ...
type Process a = Clock -> a
type Clock = Tree Time
left :: Clock -> Clock
right :: Clock -> Clock
A clock tree is composed of a node holding a non-negative integer denoting the current time and two sub-trees containing the times of future events. As the tree is (lazily) evaluated each of the nodes is instantiated with the value of system time at the time at which the node is instantiated, thus giving programs reference to the current time. […]
type Time = Integer -- must be zero or larger
data Tree a = Node { contents :: a,
left :: Tree a,
right :: Tree a }
currentTime :: Clock -> Time
currentTime = contents
Regarding Harrison’s semantics:
(page 53)
The semantics of Ruth given in Chapter 5 assume a normal order evaluation strategy such as is provided by the technique of lazy evaluation […]. Consequently whererec can be used to define infinite data structures.
Some interesting points here, but I don’t think the change of representation would matter too much here. The memory leaks in question are purely implementation problems (using GHC weak pointers and accidentally keeping them alive for too long). It may also be worth noting that reactive-banana has no internal notion of time (as in, time is not explicitly tracked). @HeinrichApfelmus is better suited to talk about the overall design and memory behavior!
