Specifically, the implementation of Time. I have some options, and would like your opinion. Facts: - There are two serious options for joining (eg. join :: m (m a) -> m a) futures, and by extension events/reactives/behaviour. Picking the largest time value, or summing them. Both are useful in different scenarios. - There are essentially two variants of time; absolute and relative. Absolute time might be represented as nanoseconds since 1970, while relative would be relative to some arbitrary starting point. Currently, and in conal's reactive, they are not differentiated. After giving it some thought, I believe that it would be reasonable to split Time in two types; one for representing absolute time, one relative; of course parametrizing the event/etc. types on the Time type the same way it's done in reactive. The join operators would be implemented as using a Monoid instance on the time types, which act a bit differently, depending. When mappending absolute times, the max of the two times would be used, with mempty of course MinBound. For relative times, the times would be summed; mempty = 0. One thing I'm not entirely sure about is the interface between absolute and relative time. Probably, the best option is to have a specialized join function for absolute :. relative -> absolute; other requirements will likely surface over time. This setup lends itself well to many common cases. When mapping one event occurence to an event consisting of multiple reactions spread over time, the reactions are naturally relative to the original occurence; using a sum function to join them, you won't have to care about exactly when that original happens. What do you think? Sounds reasonable? Lastly one ability that would take implementation effort all out of its proportion to its usefulness is the ability to subtract two absolute times, giving a relative time, and have that time provide partial information at any point before both absolute times are fully defined. If any of you would like that, and have a good reason, now is the time to speak up; doing it later would only increase the needed effort (though not beyond the bounds of Time.hs). -- Svein Ove Aas
On 30 Jul 2009, at 22:40, Svein Ove Aas wrote:
One thing I'm not entirely sure about is the interface between absolute and relative time. Probably, the best option is to have a specialized join function for absolute :. relative -> absolute; other requirements will likely surface over time.
Looks like an AdditiveGroup instance to me.
This setup lends itself well to many common cases. When mapping one event occurence to an event consisting of multiple reactions spread over time, the reactions are naturally relative to the original occurence; using a sum function to join them, you won't have to care about exactly when that original happens.
What do you think? Sounds reasonable?
Seems sensible to me -- you can add time intervals and get new time intervals.
Lastly one ability that would take implementation effort all out of its proportion to its usefulness is the ability to subtract two absolute times, giving a relative time, and have that time provide partial information at any point before both absolute times are fully defined. If any of you would like that, and have a good reason, now is the time to speak up; doing it later would only increase the needed effort (though not beyond the bounds of Time.hs).
That would certainly be nice (and required by AdditiveGroup), but it does sound a little problematic... Suppose we set up a situation where an interval i is constructed by subctrating two times a and b... We then want an event c at time b+i/2. It's possible (probable even?) that the time of c will only be determined after a has passed (too late). Is the semantics here that c occurs at the first time its occurrence time is known to be less than "now"? Bob
This may not constitute an overly constructive addition, but the
mathematical structure that combines absolute/relative time in this sense
would be a torsor
http://math.ucr.edu/home/baez/torsors.html
S
[erm, sorry for sending it to just you first thomas :P ]
On Thu, Jul 30, 2009 at 9:40 PM, Svein Ove Aas
Specifically, the implementation of Time. I have some options, and would like your opinion.
Facts: - There are two serious options for joining (eg. join :: m (m a) -> m a) futures, and by extension events/reactives/behaviour. Picking the largest time value, or summing them. Both are useful in different scenarios. - There are essentially two variants of time; absolute and relative. Absolute time might be represented as nanoseconds since 1970, while relative would be relative to some arbitrary starting point. Currently, and in conal's reactive, they are not differentiated.
After giving it some thought, I believe that it would be reasonable to split Time in two types; one for representing absolute time, one relative; of course parametrizing the event/etc. types on the Time type the same way it's done in reactive.
The join operators would be implemented as using a Monoid instance on the time types, which act a bit differently, depending.
When mappending absolute times, the max of the two times would be used, with mempty of course MinBound. For relative times, the times would be summed; mempty = 0.
One thing I'm not entirely sure about is the interface between absolute and relative time. Probably, the best option is to have a specialized join function for absolute :. relative -> absolute; other requirements will likely surface over time.
This setup lends itself well to many common cases. When mapping one event occurence to an event consisting of multiple reactions spread over time, the reactions are naturally relative to the original occurence; using a sum function to join them, you won't have to care about exactly when that original happens.
What do you think? Sounds reasonable?
Lastly one ability that would take implementation effort all out of its proportion to its usefulness is the ability to subtract two absolute times, giving a relative time, and have that time provide partial information at any point before both absolute times are fully defined. If any of you would like that, and have a good reason, now is the time to speak up; doing it later would only increase the needed effort (though not beyond the bounds of Time.hs).
-- Svein Ove Aas _______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive
participants (3)
-
Stephen Lavelle -
Svein Ove Aas -
Thomas Davie