[reactive] New implementation: Reactant (99% incomplete)

[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
_______________________________________________
Reactive mailing list
Reac...@haskell.org
http://www.haskell.org/mailman/listinfo/reactive

[Svein Ove Aas]

[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_______________________________________________

[Conal Elliott]

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