[Haskell-cafe] [ANN] frpnow-0.12
mike at proclivis.com
Tue Aug 25 04:27:39 UTC 2015
> The implementation in the library is essentially the same as in the paper, but B (E [a]) instead of B (E a) allows multiple simultaneous events, whereas the implementation in the paper does not. The result is B (E [a]), where the list is the list of all results in the event stream which occur at that point. Like the implementation in the paper, the behavior switches as soon as the next event occurs.
It looks like ‘merge’ will take two streams in, one stream out, such that if the input streams have a simultaneous event, they get put into the same array [a]. nextAll seems to get all the events, and next takes the head, and the remainder is lost. Perhaps with some trick they can be separated back into individual streams. Given this, it seems the array is more about merging and splitting streams so that things that happen at the same time do not have to be forced into some arbitrary order.
But, suppose you have a synchronous system of measurements, such that you want to intentionally put simultaneous events into a stream? Say the events are:
Sensor 1 Meas (E1)
Sensor 2 Meas (E2)
Sensor 3 Meas (E3)
and we can assume they are measured at the same time (one async call), so they are time correlated. We may then want to filter them as a pair, etc. Or there may be logic that if two events that occur at the same time and are in some relation, it triggers a new event E4 as an output. Or we might combine measurements into estimates, like in an estimator with multiple sensors, etc. Your probably guessing I’m a hardware guy :-)
Now we could tuple them, and that would work fine, and merge would work fine, but then the events must be of a fixed number. Suppose some events are sampled at different times, so we might want events in the stream to look like:
[E1, E2, E3]
[E1, E2, E3]
And say we want to generate the stream with callbackStream, so that one callback call sends the events, and they are put into the list as simultaneous.
Now, I am guessing the answer is going to be that this is an abuse of the design intent, and perhaps the tuple could just be a tuple of Maybes, and that in most systems, the number of simultaneous events is fixed, etc. But in systems where sensors can be added or subtracted, and where the type of events are somewhat arbitrary or there may be optional redundency, I can imagine that adding an arbitrary number of events into a stream and having processing that can examine the contents of the stream and adjust to what is present might be nice.
Do you have any advice on how to insert events into the stream simultaneously, and ways to split a stream into parallel streams, etc.
More information about the Haskell-Cafe