[reactive] join/mappend bug and unamb

[Conal Elliott]

I've been plugging away on some persistent & subtle Reactive bugs.  Here's a
progress report.

I changed the type of future times in Reactive and have apparently fixed the
old join/mappend bug as I'd hoped.  This bug shows up at least in the form
of delaying response to inputs.

The key for the fix was to replace AddBounds (Improving t) with Improving
(AddBounds t), since the latter type allows more partial information to seep
through than the former.  The old representation thwarted
laziness/partiality by requiring an outer discrimination between finite and
infinite times.

The new code relies on unamb more than the old code, and runs afoul of the
problems described in
http://conal.net/blog/posts/smarter-termination-for-thread-racing/ and the
comments that follow it, as well as one or two email threads.

Fortunately, Spencer Janssen's hypothosis (thunks get permanently evaluated
to aborted computations, leading to ThreadKilled and NonTermination
exceptions) validated by Sterling Clover, explains all of the troublingly
strange behavior I've seen in Reactive and may point in the direction of a
solution.

Luke Palmer has some encouraging early results with a custom scheduler that
implements unamb.  I don't know how it deals with termination of redundant
computation and whether it falls afoul of the problems I'm having with the
various race implementations floating around.  I also don't know how much of
the problem that Luke is solving comes simply from the failure of my race
implementation to kill threads recursively.

That's it for now.  I'd really appreciate help with getting a correct &
efficient implementation of thread management for unamb.

  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/reactive/attachments/20081226/ae220666/attachment.htm