Am 03/31/2015 um 10:27 AM schrieb Oleg Grenrus:
Your Temporal type looks semantically very similar to FRP’s Behaviour.
Following http://conal.net/papers/push-pull-frp/ :
We could specify the time domain as `Maybe Time`, where - `Nothing` is “before everything - distant past”, needed for “temporal default”, - `Just t` are finite values of time
newtype Behaviour a = Behaviour (Maybe Time -> a)
It’s quite straightforward to verify that your Temporal and this Behaviour are isomorphic, assuming that `Change`s are sorted by time, and there aren’t consecutive duplicates.
I find this “higher-order” formulation easier to reason about, as it’s `(->) Maybe Time`, for which we have lot’s of machinery already defined (e.g. Monad).
I am certainly not happy with my definitions type Time = Integer data Change a = Chg { ct :: Time, -- "change time" cv :: a -- "change value" } deriving (Eq,Show) data Temporal a = Temporal { td :: a, -- "temporal default" tc :: [Change a] -- "temporal changes" } deriving (Eq, Show) because writing join turned out to be such a nightmare. I like your approach of wrapping a function instead of data, but the problem is, I can no longer retrieve the times (I cannot print a "resulting schedule"). But that could easily be fixed by also returning the time of the next Change: newtype Behaviour a = Behaviour (Maybe Time -> (a, Time) However that gets me in trouble with the last change, where there is no next change. Returning Nothing in that case won't help either, because then Nothing would have two meanings (distant past and distant future). So I need a different notion of Time, which includes these two special cases. I will give that a try. Still I don't understand why my original definition gave me so much trouble. I mean it all looks quite innocent. I tried to find flaws from 10000 feet above and the only thing I could find is that the type a is mentioned in both Change and Temoral and Change alone does not make much sense. Maybe you find some more flaws.