New implementation: Reactant (99% incomplete)
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. -- Svein Ove Aas
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. -- Svein Ove Aas -- Svein Ove Aas
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.
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). Cheers Bob
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
On Wed, Jul 29, 2009 at 11:32 PM, Thomas Davie
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.
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).
Cheers
Bob_______________________________________________
Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive
participants (4)
-
Conal Elliott -
Svein Ove Aas -
Svein Ove Aas -
Thomas Davie