By all means, please make use of the Reactive QuickCheck tests (many/most of which Bob wrote) as you go.
I'd love to see unamb/lub get more attention as well. It's a tremendously powerful tool for improving the modularity of pure, functional programming. Perhaps as much as laziness. Sure it raises implementation challenges, but so did laziness.
Regards, - Conal
Glad to see there's (yet more) people working on fun ideas for how to get this lovely API to work well. Something I'd suggest though – Conal's reactive has quite a large set of tests, mostly checking that the implementations of the various classes respect the laws they're meant to, but also checking a few other things. It'd be really lovely if you could copy/paste them over to check you're sticking to the semantics as it was originally envisaged (IIRC, conal's doesn't quite, but is very close).
On 30 Jul 2009, at 00:18, Svein Ove Aas wrote:
In the interest of throwing code out early, at
http://github.com/Baughn/Reactant/tree/master there is now the first
draft of a different approach to Conal-style FRP.
Well, I say "first draft", but the code in there currently only
implements ITime - eg. Improving Time. Fortunately that's also the
hardest bit; the source of most of the bugs, and the reason to use
unamb.
This implementation doesn't use unamb, though. Instead, I'm using a
push-style approach, where the various function calls - compare, etc.
- use semaphores to block until the ITimes they are comparing are
sufficiently defined for them to return an answer.
It's my hope that, although this approach is also quite bug-prone, I
will be able to side-step the issues with unamb this way. If nothing
else, performance should increase noticably; there is no need for this
system to fork any threads except to deal with timeouts, thus forking
happens considerably less often than with unamb.
I'll hopefully have more for you in a few days. Until then, you may be
entertained by looking closely at the rather eldritch code, and if
anyone spots a potential bug, that's just a bonus.
Cheers
Bob_______________________________________________