Hi Chris,<br><br>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.<br>
<br>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).<br>
<br>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.<br>
<br>Regards, - Conal<br><br><div class="gmail_quote">On Fri, Jul 10, 2009 at 7:54 AM, Chris Lesniewski-Laas <span dir="ltr"><<a href="mailto:ctl@mit.edu">ctl@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Fri, Jul 10, 2009 at 04:47:49PM +0200, Svein Ove Aas wrote:<br>
> I can't comment on this exact bug, but in general the Monad instance<br>
> for Event is semantically broken.<br>
><br>
> There's a perfectly reasonable joinE function, yes, but as I<br>
> understand it combining it with the perfectly reasonable Applicative<br>
> instance produces an illegal monad. Thus, in general, you should avoid<br>
> the Monad instance and use joinE directly when required.<br>
<br>
</div>For what it's worth, the same problem appears to be present if I use<br>
joinE directly instead of join/>>=. I've experimented a lot with<br>
variations on joinE's implementation.<br>
<br>
If it is going to be possible for one input packet to result in multiple<br>
output packets, I'm going to need some function from Event (Event a) to<br>
Event a. switchE is clearly not it. joinE seems to be the right idea,<br>
although I'm unclear on the semantics when an inner event has<br>
occurrences predating its own occurrence in the Event (Event a).<br>
<font color="#888888"><br>
Chris<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Reactive mailing list<br>
<a href="mailto:Reactive@haskell.org">Reactive@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/reactive" target="_blank">http://www.haskell.org/mailman/listinfo/reactive</a><br>
</div></div></blockquote></div><br>