• Simplified the definition of joinE in 7.2.2
• Simplified (a bit) the unamb “reference implementation” in Figure 4, noting that it is not an efficient implementation.

joinR :: Reactive (Reactive a) -> Reactive a
joinR :: ((a `Stepper` Ev ur) `Stepper` Ev urr) =
         a `Stepper` Ev u
     where u = ((`switcher` e')  ur) `mappend` (join  urr)

Before completing the definition of u, you say that it is the first of either (`switcher` Ev ur) <$> ur or join urr.

In actual definition of u in your paper, you use e', which was never bound. I believe e' is supposed to be Ev urr. Before completing the definition of u, your intermediate code ((`switcher` Ev ur) <$> ur) uses neither e' nor Ev urr, but uses Ev ur instead.

I started out with that simpler definition. Here’s what I think is a problem with it: Concurrent Haskell has no atomic operation for reading an MVar. The readMVar action instead does a takeMVar followed by a putMVar. After the reader’s takeMVar and before its putMVar, the race-loser could unblock and do its putMVar. This second putMVar to the same MVar would break the pure semantics and would cause the reader to block instead of completing its readMVar. I hadn’t considered this possibility until Ivan Tomac pointed it out.

a `race` b =
  do  v <- newEmptyMVar
      let run io tid = forkIO $ do x <- io
                                   putMVar v x
                                   killThread tid
      mdo ta <- run a tb
          tb <- run b ta
      readMVar v

Well, maybe this issue is moot anyway since you and Ryan Ingram seem to have come up with some nicer way of doing this.

Future (Max MaxBound,_) `mergeu` v = v
u `mergeu` Future (Max MaxBound,_) = u

I just added these lines to the implementation. Thanks for pointing out the leak.

Of course you need to plumb into the implementation details when you are writing the interpretation functions (occs/sinkE/sinkR), unless you take waitFor and force as primitive as well, which severely constrains the design of Future. But most client code can absolutely ignore that and use the behavior/reactive/event abstraction.

(3) From your definition of mappend on events:

u `mergeu` v = (inFutR (`merge` v) <$> u)
           <+> (inFutR (u `merge`) <$> v)
   where
       inFutR f (r `Stepper` Ev u0) = r `Stepper` Ev (f u0)

Consider the case where v = never. The rhs of <+> goes away, but we still call “merge” in the lhs, and pass v again. So any storage held by v cannot be reclaimed, and there’s also a time leak as <+> keeps getting called needlessly.

The more merges that happen, the worse the leak gets.

(1) You’ve lost the “edge” constructors for events [...] You can implement them for Reactive instead of Behavior, but it’s impossible to do so for Behavior itself.

Agreed, given that a behavior can be any (computable) function of time and the semantics of the edge operations require capturing every transition and capturing it exactly. There are some variations on the Behavior type, such as derivative bounds, that would allow catching each transition, while retaining continuous time.

I think it’s possible to implement this less powerful operation [...] which filters the “tick” event list to only contain occurrences where the behavior changed from False to True between one tick and the next.

I don’t know where the idea of a “tick” could fit in FRP’s continuous-time semantics. Perhaps you’re thinking of a temporally discrete variation.

(2) The entire reactive system can be parametrized on the definition of Future; futures need the following operations: [...]

I may be missing your point. Are you saying that futures are only used through the Future interface?

(3) merging event streams leaks memory [...] Once a connection is closed, it can’t possibly give any more events, but the event merge listens to it forever.

Why do you expect event merge (mappend) to keep listening to an event that knowably cannot have any more occurrences? An event is represented as a future, and that future can have an explicitly infinite (MaxBound) time. (See Section 4.5 and Figure 1.) Since mappend on events works via mappend on futures, and the latter handles infinite time, I think your example would work out easily enough without a space leak, assuming that the event reflects the closed connection with an infinite-time future (analogous to a nil at the end of a list).

(3) merging event streams leaks memory; consider a long-running server application of this type:

type Connection = (Event Char, Char -> IO ()) -- TCP
listen :: Int -> IO (Event Connection) -- listen on a TCP port
server :: Event Connection -> Event (IO ()) -- server actions

Somewhere inside of “server” there would be an event join which allows the server to extract data from a connection; this eventually results in an mappend between a future connection and a future character from a connection. Once a connection is closed, it can’t possibly give any more events, but the event merge listens to it forever.

This can be solved with this additional operation on futures:

whenNever :: Future t a -> Future t b -> Future t b
-- semantics:
-- whenNever never f = f
-- whenNever _     _ = never

mergeE :: Event a -> Event a -> Event a
mergeE (Ev e1) (Ev e2) = Ev $
    -- if e2 is "never", throw it away
    whenNever e2 e1
    -- if e1 is "never", throw it away
    `mappend` whenNever e1 e2
    -- if e1 arrives first, use it
    `mappend` fmap (\(Stepper a e1') -> Stepper a $ mergeE e1' (Ev e2)) e1
    -- otherwise use e2
    `mappend` fmap (\(Stepper a e2') -> Stepper a $ mergeE (Ev e1) e2') e2

Implementing whenNever is tricky, though. The best I’ve done so far is have an explicit representation for futures that are Never; another option is to dynamically allow a future to become “Never” although that could break the axioms of futures. The best solution, I think, is to have whenNever delay the second future to the point at which we can determine the first future is never; if it’s immediately obvious (“pure” never) we can return f directly, otherwise we may delay f’s occurrence. This doesn’t break mergeE at all, but it does complicate the semantics of whenNever.

(1) You’ve lost the “edge” constructors for events:

risingEdge :: Behavior Bool -> Event ()
fallingEdge :: Behavior Bool -> Event ()

You can implement them for Reactive instead of Behavior, but it’s impossible to do so for Behavior itself. That said, maybe that’s a good thing; they can’t possibly detect the exact edge in any system that lets you define behaviors with fmap or arr. I think it’s possible to implement this less powerful operation:

risingEdgeAcrossTick :: Behavior Bool -> Event () -> Event ()
risingEdgeAcrossTick beh tick = ...

which filters the “tick” event list to only contain occurrences where the behavior changed from False to True between one tick and the next.

(2) The entire reactive system can be parametrized on the definition of Future; futures need the following operations:

type Future t a -- abstract, although assume Eq t, Ord t, Bounded t

-- given the semantics from the paper
instance Functor (Future t)
instance Applicative (Future t)
instance Monad (Future t)
instance Monoid (Future t a) -- mappend = firstFuture, mempty = never
instance MonadPlus (Future t) -- see Monoid

-- plus these additional two operations:
exactly :: t -> a -> Future t a
   -- force (exactly t a) = (t, a)

withTime :: Future t a -> Future t (t,a)
   -- force (withTime f) = withTimeSem (force f) where
   --    withTimeSem (t,a) = (t, (t,a))

(1) Absolutely: that was the goal. In particular, here is the implementation of “force”:

type FTime t = AddBounds t
type F t a = (FTime t, a)
force :: Future t a -> F t a
force f = unsafePerformIO $ allowNestedTransactions $
             atomically $ value f

allowNestedTransactions is a hack I came up with to do, well, what its name says:

allowNestedTransactions m = do
    v <- newEmptyMVar
    forkIO (m >>= putMVar v)
    takeMVar v

This uses a separate thread to trick the STM runtime into allowing a nested transaction, but the behavior is exactly that of a single-threaded program; the MVar handles control flow and makes sure that the originating thread blocks until the computation on the forked thread completes. Ideally this won’t be necessary in a future implementation of STM. Of course this is only required if “force x” is used as a pure value inside another STM computation, and none of the reactive code calls force except for “occs”. But pure values should act like pure values, so something was required.

(2) Exactly; here are the requirements for a correct future: If f denotes (t0, a), then:

waitFor f t ~> return ()
  => forall (s <= t). waitFor f s ~> return ()
-- That is, if waitFor f t doesn't retry, then waitFor f t
--   doesn't retry for earlier t either.

waitFor f t >> maybeSTM (value f) ~> return Nothing
   => t0 > t
-- That is, if waitFor f t doesn't retry, and value f
--  does, then f is not yet available at time t.

Another way to look at it is to treat each future as having a universe which has its own current time. Then we have the following rules:

now :: Future a -> STM Time -- never retries

waitFor f t = do
    n <- now f
    if (t <= n) then return () else retry
-- In fact, I define "now" for a future as "the largest t
--   such that waitFor f t does not retry"

value f = do
    n <- now f
    if (n >= t0) -- this is the t0 from the denotation of the future
      then return (t0, a)
      else retry

now (pure x) = return maxBound
now (firstFuture f1 f2) = min <$> now f1 <*> now f2

So, in “firstFuture”, this code snippet:

        (Just (t1, v1), Nothing) -> do
            waitFor f2 t1
            return (t1, v1)

says “synchronize this future with f2 until at least time t1″. If (now f2) is less than t1, then this will retry and the transaction should get re-run when either (a) (now f2) >= t1, or (b) the results of maybeSTM (value f2) changes, that is, f2 resolved to a particular value.

(3) I’m sure I haven’t done this properly yet, but it should be pretty easy to solve with a TVar that holds the value of the future once it gets determined; the caching problem seems to apply more to Events (streams of futures) than futures themselves; a future will only ever return its single correct value or retry. I suppose that in the <*> case that the first future could resolve, and then we will go through and re-calculate it when the second future resolves. I’ll think about that and see if I can come up with a good solution.

Overall, STM doesn’t seem -quite- as good a fit as I originally thought; the idea of a value that becomes known through computation and then stays that way is exactly what a pure value does via laziness. I need to think about this problem some more, but it’s been a lot of fun!

• Does your Future a type have the same denotation as in my paper, namely (Time,a)? Does firstFuture have the same semantics as my mappend (picking the earlier future)?
• What use do you make of waitFor? Related: what’s the semantics of firstFuture, and what do its calls to waitFor accomplish? I see the comment “start over if something changes in the meantime”, but I don’t see how the waiting influences the returned value, so I don’t know how you could get determinate semantics. Does waitFor sometimes retry?
• What’s your implementation of fmap and (<*>) on your Future representation, and have you checked whether it re-applies functions each time the result is accessed? My first implementation used STM in a similar way, and I realized that the obvious (to me) fmap and (<*>) implementations failed to cache their values. My fix (and Jake McArthur’s–see comments on your post), used a writer thread.