Alternative vs Monoid?

[safareli]

Based on semantics of Behavior and Event i think there is no need for Monoid a constraint. and if it's true, then Behavior and Event can be Monoid for any a i.e. instead it could be an instance of Alternative

[conal]

Thanks! I just removed the Monoid a condition from the Monoid (Event a) instance in the slides. I think the Monoid (Behavior a) instance still needs Monoid a.

[conal]

I agree with your point that Event could (also or instead) be given an Alternative instance.

[safareli]

Ah yes Behavior will need Monoid a constraint as you have a-s from both Behavior and you need a way to combine them. so it can't be Alternative.

But if we have two Event a which contain values for same T, then we have two choices:

• either output first value and then second
• or add Monoid a constraint, use append for a and output one value at the T

[conal]

Agreed---both options for combining Event a are possible. The one without the Monoid a constraint agrees with the original FRP semantics. I think it's also a better choice. One reason is that it follows from the semantic type class morphism principle (TCM) if the denotation of Event a is T -> [a] (restricted to discretely non-empty). (For Functor, I think we'd instead want the isomorphic form ((->) T :.: []) a, where (:.:) is functor composition, which also then determines the Applicative Event instance.) I'm exploiting that [a] is a monoid. One could also use [a] itself as the monoid, in which case events become list-valued, discretely non-empty behaviors. Then optionally generalizing from [a] to any monoid. Then the discretely non-empty restriction would become discretely non-mempty. I don't know whether that generalization still makes precise & useful sense for reactivity, since general non-mempty-ness is neither clearly a non-occurrence, nor decidable.

[safareli]

Well, I don't understand most of the staff after --- :d
Anyways, thanks for the talk!