Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generalisation of Events and Behaviours #11

Closed
erisco opened this issue Mar 14, 2014 · 2 comments
Closed

Generalisation of Events and Behaviours #11

erisco opened this issue Mar 14, 2014 · 2 comments

Comments

@erisco
Copy link

erisco commented Mar 14, 2014

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-real-blackh
Copy link

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.

@erisco
Copy link
Author

erisco commented Mar 14, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants