Mitchell Dalvi Rosen

Yup, and the implementation is just a variation of `unionWithP`: ```haskell intersectionWithP :: (a -> b -> c) -> Pulse a -> Pulse b -> Build (Pulse c) intersectionWithP f...

Well there used to be a `union` function before version 1.0, so the name `unionWith` made more sense. Now that `union` no longer exists, I'd prefer to simply rename `unionWith`...

I think its `reactive-banana` type would actually be this: ```haskell mergeWith :: (a -> b -> Maybe c) -> (a -> Maybe c) -> (b -> Maybe c) -> Event...

Hmm... I'm not sure :) On one hand, I do find I need this combinator, or something like it, a lot. But on the other hand, I don't like how...

Last I looked - and my understanding could be way off here - the `Cached` type is actually not necessary, it just serves as sort of a reminder that some...

Thanks for the clarification, that is subtle indeed... so subtle that I'm not sure I understand it yet! Simplifying the machinery a tiny bit, let's say I decorate an IO...

Could this concept simply replace `fromPoll`? `fromPull` has the same type signature, and pulling only wen necessary seems preferable to polling on every input event.

> Note that the implementation of fromPull does not need a LatchWriter, the purpose of the latter is only to connect a Pulse and a Latch. In this case, everything...

Whoops :) The returned event emits whenever the outer and inner events emit simultaneously.

As a motivating example, here's a simple first-order rendering of some widgets: ```haskell -- render event and rendering function eRender :: Event () render :: [Widget] -> IO () ```...