[reactive] Temporal mechanics

[Stephen Lavelle]

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 <sveina at gmail.com> wrote:

> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/reactive
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/reactive/attachments/20090912/43b8a2c2/attachment.html