Hi Peter,

I don't need unamb stuff since I just spawn one new thread for each merged event, and I use the WaitForMultipleObjects primitive to check which of the two event occurrences was first.

By "was first", do you mean the occurrence itself or when it was detected?  The latter is easier to implement but disagrees with the semantics (see http://conal.net/blog/posts/future-values-via-multi-threading/), which is what eventually led me to unamb.

I don't know what it takes to create and use a FRP library with pure semantics in a strict language (like C# and F#).

Since you're using WaitForMultipleObjects and working in strict languages, you might find Mike Sperber's thesis helpful: http://w210.ub.uni-tuebingen.de/dbt/volltexte/2001/266/pdf/lula-thesis.pdf .  He doesn't get the simple pure semantics of classic FRP or Reactive, but he does explore some of the complex issues of dealing with FRP in a strict setting.

I'd love to hear how your experiment goes.

    - Conal

2008/12/26 Peter Verswyvelen <bugfact@gmail.com>
I'm building a little Reactive library in C# for fun - in the same spirit as Conal's one - with the intension to convert that to F#, which I'm learning now.

Right now I implemented  Future, Event and Reactive, and functionality to merge/mappend two events.

Although I'm not yet sure it fully works, using some tricks from Reactive, it was actually really easy to implement. I don't need unamb stuff since I just spawn one new thread for each merged event, and I use the WaitForMultipleObjects primitive to check which of the two event occurrences was first. The code is of course a zillion times more ugly than in Haskell, and since I'm not using lightweight threads, it might really be slow. I tried to make it as immutable as possible, so it's not really imperative :) 

But what is the minimal set of functions one must implement to build a Reactive library, in the sense that all others can be implemented using these?

Merry Xmas!