On Tue, Jun 7, 2011 at 6:14 AM, Casey McCann <syntaxglitch@gmail.com> wrote:

On Mon, Jun 6, 2011 at 7:55 PM, David Barbour <dmbarbour@gmail.com> wrote:
> Earlier forms of my reactive demand programming model [1] - before I
> switched to arrows - would qualify. The model has limited side-effects (e.g.
> power a camera on only when someone is observing it) so we cannot use
> branchApplicative. The reactivity requires continuously weaving the two
> branches over time and recombining the results, which is distinct from
> branchMonad.

Oh, very nice, thank you. I'd actually suspected that models of
reactive behavior might be a case where the distinction is meaningful.
I do still wonder if there's something roughly equivalent to the
(grossly inefficient and unusable, but producing the same results
otherwise) monad instance for zipping infinite streams, but I don't
have time to work through it right now to be sure...

The main trouble with using monads directly is that they're simply too powerful. Monads allow ad-hoc joins and loops based on data. The number of reactive relationships during any given instant can vary widely and unpredictably based on data. This makes it difficult to maintain stable relationships over continuous time. Looping and Branching must be carefully managed in my reactive model in order to gain stability over time that Monads do not possess.