Functional reactive programming library
#9Add EventLike class and UniqueEvent
This adds new event type called UniqueEvent. It is an Event which is supposed to be unique for each step, that is, if a wire observes an UniqueEvent on its input on two different ticks, it can assume that these are completely different events. This enables one to, in addition to usual intervals-related event handling, extract Maybe from an Event or apply a monadic action to it.
Some functions already produce UniqueEvents in fact (they were converted) -- such as 'now' or 'at'; other functions can produce any kind of events (like 'never'). All functions which worked with events were converted to work with any kind of events. In addition, functions 'onUEventM' and 'fired' were added, which work only with UniqueEvents.
The biggest problem of this patch is that we can't fully guarantee main assumption of UniqueEvent with types; it can be broken with a wire that saves incoming UniqueEvent and re-emits it later.
Any ideas for adding more type safety? Maybe I've misunderstood assumptions behind Event, and this isn't the right approach?
Issue BundleSorry for so many edits, I'm discovering better sets of UniqueEvents-related functions.
I don't know why I haven't done this before, looks like this set would be the final one. That lefts only the problem of insufficient type safety. That's better in my opinion that current state of affairs, though -- user needs to use Unsafe primitives each time he works even with guaranteed good-behaving events, and with this he would know that if he wouldn't do really stupid things like re-throwing events, everything should be fine.
Ouch, old patch.
More conversion from (Event a) to (Event Like ev => ev a).
I'm not sure I understand the semantics of UniqueEvent. Could you explain it in terms of an example?
- added tag feature
Sorry for taking a long time, I was sure that I'd get a e-mail notification, so I haven't checked the issue page.
UniqueEvent was born from my understanding that Events in netwire are meant to be analyzed "on edge" and not "on level". For example, hypothetical
became isKeyPressedcannot be analyzed "on level" because we can't be sure that event occurences at t-1 and t correspond to different physical events. If I understand correctly, it's for that reason thatoccurredand any functions that act on events "on level" are considered unsafe. Instead we haveasSoonAsand friends who act "on edge".UniqueEvent adds a new type of event that can be analyzed "on level". That guarantee must be provided by someone who has constructed an event. This allows us to make functions like
onEventMandoccurredsafe when used on this type of events. Some existing event sources are already safe in that sense, likeperiodic-- we can safely assume that ifperiodic's signal is high at t and t+1, it means that two different events have occurred.If my reasoning w.r.t. current assumptions about events is wrong, please correct me!
