If an FRP library provides first-class signals then often the problem arises that these are actually signal generators—their behavior might depend on the time they are started. To get rid of this deficiency, my signal types now have an additional type argument which denotes the starting time. This way, I’m able to fix the starting time using the type system. The idea is similar to the usage of the “state” type argument of ST.
Dependencies on an absolute clock always caused trouble in Fran/FRP programming and were one of the things I tried to get rid of in my FunWorlds experiments (sigh, way too long ago..). Thinking of behaviours as functions from *all* times to values is an unimplementable theoretical ideal and completely at odds with FRP's more practical ideal of compositional programming (leading to the less sung about "arts" of actual programming in FRP, aging behaviours, start times, etc.). Thinking of behaviours as something one can do measurements on, yielding current value and residual behaviour, leads to simpler semantics, implementation and programming. If you want a (local!) clock, just integrate over a constant. Many of the FunWorlds aspects would need revision, if I ever get round to that.. but dropping absolute time was the right thing to do (as if physics hadn't told us about that anyway;-). Claus