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 often write this somewhat boilerplatey definition of a Behavior:
eFoo <- accumE x eUpdate
bFoo <- stepper x eFoo
This is typical, because at times I want to sample a behavior, and at other times I want to express something in terms of the events that update it.
It's unsatisfactory because:
I have to manually make sure that I pass in the same initial value x
The event and behavior are "linked" by name alone, but they are very related to each other.
I've read the documentation to changes multiple times, and I think I understand the appeal to the semantics of a behavior as a time-varying value with no concept of a discrete step from one value to another.
However, in code as above, it feels like I have a little backdoor to these semantics. All I've done is manually roll my own accumB and suddenly I do have a handle on the discrete steps that the behavior undergoes.
Given this, I'm a little unsure of why Behavior takes care to throw away the underlying Pulse a of updates in favor of a Pulse () that fires at the same time.
I'm curious to know what (whoever's listening's) thoughts are on this, and about the Dynamic type from reflex, which seems to attempt to solve this problem by just paring up a Behavior with an Event that carries its updates. reactive-banana notably doesn't have this convenience type; is it to keep the API simple, or because it is an odd type semantically, or something else?
Thanks =)
The text was updated successfully, but these errors were encountered:
The benefit of having a Behavior type where you can not get the changes is that any code using this code is guaranteed to be independent of the frequency of ("spurious") changes. For example, if you consider a slightly different event and behavior,
eFoo' <- accumE x $ unionWith (.) eUpdate (id <$ eSomeOtherEvent)
bFoo' <- stepper x eFoo'
then the behaviors bFoo' are bFoo are nonetheless semantically equal, even though they arise from accumulations of events that not equal.
In practice, I found a Tidings type more useful than Dynamic. The key difference is that the values contained in the rumors need not occur in the facts at all.
I often write this somewhat boilerplatey definition of a Behavior:
This is typical, because at times I want to sample a behavior, and at other times I want to express something in terms of the events that update it.
It's unsatisfactory because:
x
I've read the documentation to
changes
multiple times, and I think I understand the appeal to the semantics of a behavior as a time-varying value with no concept of a discrete step from one value to another.However, in code as above, it feels like I have a little backdoor to these semantics. All I've done is manually roll my own
accumB
and suddenly I do have a handle on the discrete steps that the behavior undergoes.Given this, I'm a little unsure of why
Behavior
takes care to throw away the underlyingPulse a
of updates in favor of aPulse ()
that fires at the same time.I'm curious to know what (whoever's listening's) thoughts are on this, and about the
Dynamic
type fromreflex
, which seems to attempt to solve this problem by just paring up aBehavior
with anEvent
that carries its updates.reactive-banana
notably doesn't have this convenience type; is it to keep the API simple, or because it is an odd type semantically, or something else?Thanks =)
The text was updated successfully, but these errors were encountered: