do a <- future (return 0)
   b <- (+1) `fmap` a
   c <- (+2) `fmap` a
   val_bc <- force (b `mappend` c)
   val_cb <- force (c `mappend` b)
   guard (val_bc == 1 && val_cb == 2)

to fail even though the denotational semantics say it should succeed. Even if fmap introduced a new time, it would take some tricky programming to completely avoid the possibility that (val_bc == 2 && val_cb==1), which would prove that they happened in an inconsistent order. But Improving already implements most of that tricky programming, so great!

After skimming your paper, I didn’t see a way to introduce Futures or (Improving Time)s, just the compositions. To get time to work, I think you need a global monotonic MVar counter. Then when the future gets its value, you do something like:

do c_val <- takeMVar counter
   -- Important that this happens while counter has no value:
   putMVar an_mvar_inside_the_improving c_val
   putMVar counter (c_val + 1)

and to write exact and compare_I for a particular Future, you use:

exact = unsafePerformIO $ readMVar an_mvar_inside_the_improving  -- bound from the creation of the future
compare_I other = unsafePerformIO $ do
    -- make sure that the global counter has passed other's value:
    evaluate other
    my_val <- tryTakeMVar an_mvar_inside_the_improving
    case my_val of
        -- If an_mvar... is not set any time after other was set, it's guaranteed to get a higher value.
        Nothing -> return GT
        Just val -> do putMVar an_mvar_inside_the_improving val
                       return $ compare val other

I haven’t run this, so it’s very possible it doesn’t actually work. It’s also fairly expensive to maintain that global counter on a machine with lots of processors because the cache line has to move between processors a lot, but that may be masked under other Haskell overhead.

Or have you already implemented all of that somewhere that I missed?

Also, according to http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Concurrent.html#v%3AkillThread, “if there are two threads that can kill each other, it is guaranteed that only one of the threads will get to kill the other.”, so you don’t actually need the lock in race.

I wonder if you understood what I’m after in an implementation, which is to realize (implement) the simple, determinate, denotational semantics from the earlier Future values post. That semantics includes and addresses simultaneity, and implementing it faithfully doesn’t require hardware simultaneity.

My original demand-driven FRP implementations implemented this semantics (including determinacy and simultaneity) correctly (whether on uniprocessor or multiprocessor), as does the new data-driven implementation described in Simply efficient functional reactivity.

Thread 1 Thread 2 Thread 3 Thread 4

r1 = a r3 = b a = 1 b = 1

r2 = b r4 = a

On many 4-processor systems, it is quite possible that r1 == r3 == 1 and r2 == r4 == 0, proving that a was written before b to thread 1, and b was written before a to thread 2. Not only didn’t they happen at the same time, they happened in inconsistent orders in different places. (It’s very relativistic.) When processors do allow you to eliminate this possibility, they instead guarantee that memory actions happen in a global total order. Again, no simultaneity.

So you have two choices. Either your Time parameter models the behavior of your Futures, in which case you have to arrange to use the fairly expensive sequentially-consistent instructions for reads and writes to shared variables (which guarantees that no two events will be simultaneous). Or a totally-ordered Time is inappropriate to model the semantics of Futures, and you instead have to fall back on something like the happens-before partial order that defines the Java and C++0x memory models. There may be another good semantics for this besides happens-before, but it’s unlikely to present you with the problem of events that are provably simultaneous, so even if mappend picks “wrong”, your users will never be able to tell.

P.S. I’m working on a C++ Futures library and had realized that futures were monadic, but these articles are a great summary of the realization. Thanks!

It seems to me that this is not referentially transparent: ...

To me also. I think the uses of future in Future.hs are referentially transparent. I could simply not export future or make a clear explanation of how I intend it be used.

let x = future getChar in liftA2 (,) x x

vs.

liftA2 (,) (future getChar) (future getChar)

a `seq` return a

I recommend the slightly less evil

Control.Exception.evaluate a

In the race function, what happens in the unlikely case that the two threads both perform the ‘killThread’ action before either gets to ’sink x’?

I think that could happen, and the result wouldn’t be pleasant, as there would be no winner instead of one or two. Perhaps a safer alternative would be to swap the killThread and sink lines. Then there’d be a possibility of two sinks getting through. Both sink calls would putMVar to the same MVar, which means the second call would block until its thread is killed later. But there’s still a gotcha: the readMVar operation is not atomic. It does a takeMVar followed by a putMVar. Between those two calls, the blocked putMVar thread could easily be scheduled. The result is that the same future could report two different values. I think the “simple implementation” avoids that problem by hiding the action that contains the readMVar, allowing it to get executed at most once.

I don’t expect any of these remarks to be reassuring. At least, they’re not to me.

Also, why is it a problem that in a mappend b we may get b when a and b are available simultaneously?

Because I want a clear & deterministic (denotational) semantics. Why? For tractability of reasoning. The semantics has to specify one bias or the other in the case of simultaneity.

In the race function, what happens in the unlikely case that the two threads both perform the ‘killThread’ action before either gets to ‘sink x’?

Also, why is it a problem that in a mappend b we may get b when a and b are available simultaneously?

Ivan