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