[reactive] Event's Monad instance and joinE

[Conal Elliott]

Hi Chris,

Your use for joinE is exactly the sort of thing I had in mind for the Event
monad.  The semantics is to combine all of the generated events via mappend,
which means the occurrences will be time-sorted.  But first, the inner
events are time-tweaked so as not to pre-date the occurencs that gave birth
to them.  Have you read "Push-pull functional reactive programming" (or its
nearly-identical predecessor "Simply efficient functional reactivity)?  The
semantics is spelled out precisely there, in terms of the monad instance for
Future.  The latter monad is determined by the semantics of Future
(time/value pairs, with a suitable monoid for time), according to the "type
class morphism" property (subject of another paper).  If there's something
in the paper that's not clear to you, feel free to ask for clarification.

I think there's a misunderstanding behind Svein's comment about a conflict
between Applicative & Monad instances for Event.  I gave both instances in
the paper, and mentioned why I don't expect the Applicative instance to be
very useful.  I hinted at an alternative (relative time, which simply
changes the Time monoid from Max to Sum), which would lead to different
Applicative & Monad instances -- again consistent with each other -- where
I'd expect the Applicative instance to be more useful (because sums have
more variety than maxima).

There is a problem with the monad associativity law in the current Event
Monad semantics.  I doubt that semantic problem has anything to do with the
implementation problem in joinE.  I'd guess there's a subtle laziness issue.

Regards,  - Conal

On Fri, Jul 10, 2009 at 7:54 AM, Chris Lesniewski-Laas <ctl at mit.edu> wrote:

> On Fri, Jul 10, 2009 at 04:47:49PM +0200, Svein Ove Aas wrote:
> > I can't comment on this exact bug, but in general the Monad instance
> > for Event is semantically broken.
> >
> > There's a perfectly reasonable joinE function, yes, but as I
> > understand it combining it with the perfectly reasonable Applicative
> > instance produces an illegal monad. Thus, in general, you should avoid
> > the Monad instance and use joinE directly when required.
>
> For what it's worth, the same problem appears to be present if I use
> joinE directly instead of join/>>=.  I've experimented a lot with
> variations on joinE's implementation.
>
> If it is going to be possible for one input packet to result in multiple
> output packets, I'm going to need some function from Event (Event a) to
> Event a.  switchE is clearly not it.  joinE seems to be the right idea,
> although I'm unclear on the semantics when an inner event has
> occurrences predating its own occurrence in the Event (Event a).
>
> Chris
> _______________________________________________
> Reactive mailing list
> Reactive at haskell.org
> http://www.haskell.org/mailman/listinfo/reactive
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/reactive/attachments/20090711/c4448101/attachment-0001.html