Monoid instance for Event t (a -> a) ? about reactive-banana HOT 7 CLOSED

Oh!

I don't actually know why I've commented it out. It may have been because this instance requires the FlexibleInstances or some other extension that the Utrecht Haskell compiler didn't support. It was still there in version 0.5.

I should probably enable the instance again.

from reactive-banana.

But then why not to define instance for Event t a. That instance is same as

instance Monoid a => Monoid (Event t a) where
  mempty  = never
  mappend = unionWith mappend

For that particular instance a is Dual (Endo a). Event calming could be served by separate combinator. Say calmWith :: (a → a → a) → Event t a → Event t a

from reactive-banana.

Is there a reason the Monoid Instance is still commented out?

from reactive-banana.

Well, I could not find a good reason to add it back in. The current semantics of Event a (as of reactive-banana-0.8) allows for multiple simultaneous events, so accumE can work with union or unions just fine.

However, I now lean towards disallowing simultaneous events. In this case, the monoid instance for Event (a -> a) would become much more important, and I would definitely add it back in.

from reactive-banana.

@HeinrichApfelmus so its been awhile since I read Conal Elliott's paper, but isn't that issue circumvented via unamb :: a -> a -> a?

from reactive-banana.

That's a totally different story, I am afraid.

from reactive-banana.

The unions combinator currently serves as a substitute for a possible

instance Monoid (Event (a -> a))

I would leave it at that for now. See #104 for more discussion on possible Monoid instances for Event.

from reactive-banana.