You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wrote up a proof-of-concept for the generalisation of Events and Behaviours as a small library I called Lithium (link).
The key property I used is that Reactive r (Behaviour r (Maybe a)) is isomorphic to Reactive r (Event r a), allowing me to rewrite all the core functions only using the type Reactive r (Behaviour r a).
I am not intimately familiar with Sodium so there may be semantic or runtime behaviour problems with this generalisation. To address the discreteness of events, the setter function returned by Sodium's newEvent is modified to only pulse a value; that is, to fire Just value followed by Nothing on the same transaction (line 150).
There is currently an issue with multiple firings for Lithium's behaviours on the same transaction. Particularly, only the last firing seems to occur. I am not sure if this is a bug in Sodium, my misunderstanding of how it works, or a bug in what I have done. Most critically, this problem prevents pulse from working, and thus Lithium's events are broken.
Hopefully this work helps give new insight. Critique and corrections are appreciated.
The text was updated successfully, but these errors were encountered:
Behaviour contains an underlying event, and 'value' and 'updates' expose that. While this is convenient, I think it might be a bad idea overall.
I am doing some work with Heinrich Apfelmus of Reactive Banana to see if we can come up with a common interface to our two systems. One thing I will be doing is getting rid of 'value' and 'updates', to see how that works out.
So, what I'm saying is that without 'value' and 'updates', Behaviours and Events are genuinely different.
I was scoping my considerations exclusively to Sodium itself to demonstrate the present redundancy. value and hold Nothing are the cornerstones for the isomorphism, so indeed without one of them the generalisation falls apart.
I am glad you are already aware of the similarity in Sodium's definitions for Behaviour and Event and are working for a better design.
Hopefully I can offer something more pertinent to your current work in the future.
I wrote up a proof-of-concept for the generalisation of Events and Behaviours as a small library I called Lithium (link).
The key property I used is that
Reactive r (Behaviour r (Maybe a))
is isomorphic toReactive r (Event r a)
, allowing me to rewrite all the core functions only using the typeReactive r (Behaviour r a)
.I am not intimately familiar with Sodium so there may be semantic or runtime behaviour problems with this generalisation. To address the discreteness of events, the setter function returned by Sodium's
newEvent
is modified to only pulse a value; that is, to fireJust value
followed byNothing
on the same transaction (line 150).There is currently an issue with multiple firings for Lithium's behaviours on the same transaction. Particularly, only the last firing seems to occur. I am not sure if this is a bug in Sodium, my misunderstanding of how it works, or a bug in what I have done. Most critically, this problem prevents
pulse
from working, and thus Lithium's events are broken.Hopefully this work helps give new insight. Critique and corrections are appreciated.
The text was updated successfully, but these errors were encountered: