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
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!