[Haskell-cafe] ANNOUNCE: Data.IVar 0.1

[Luke Palmer]

On Wed, Oct 8, 2008 at 12:20 AM, Don Stewart <dons at galois.com> wrote:

> lrpalmer:
> >    Several very elegant FRP approaches are emerging, most visibly
> >    FRP.Reactive, which rely on blocking on multiple variables at once,
> >    continuing when the *first* of them is available. . . inside an
> >    unsafePerformIO, so the beautiful STM "orElse" solution is not
> available.
> >     The current solution is to race threads against each other, and have
> the
> >    one that finishes first kill the other one.  This is implemented, for
> >    example, in Data.Unamb.  However, our empirical tests have shown that
> the
> >    GHC scheduler is not *quite* good enough to handle this efficiently,
> and
> >    ends up introducing too much latency and nondeterminacy.
>
> Cool! Does you IVar implementation have anything in common with previous
> proposals for things called IVar (or say, 'ports',
> http://www.cse.unsw.edu.au/~chak/haskell/ports/<http://www.cse.unsw.edu.au/%7Echak/haskell/ports/>
> )?


Yes, I picked up the name from haskell-cafe discussions a while back.
Various forms have been popping in and out of the reactive libraries.

I hadn't seen ports before.

What's the background for this abstraction?
>

So like I said, I'm not too sure, I just stole the name and vague idea from
discussions about it.  As is easily noticed from the jive above, it's
motivated by the continuous barrage of suboptimal FRP libraries.  While I'm
working on reactive from the top down, this is the beginning of one I have
planned, taking baby steps from the bottom up  (and it'll likely get
incorporated into reactive too).

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20081008/5cf530e1/attachment.htm