Am Donnerstag, 11. September 2008 00:09 schrieben Sie:
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..).
Hmm, maybe you misunderstood. The extra type argument cannot be instantiated to the current time since that would need dependent types or something similar. Actually, we never instantiate this argument but only force it to be independent to other such time arguments via forall, and force it to be equal to other such time arguments by using the same type variable multiple times in the same type. So the whole thing is only about whether something happens at the same time or not. It’s really similar to the first ST type argument without using RealWorld. You never instantiate it, you just put constraints on it in the form that it has to be equal to some other such argument.
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.).
At least, I try to help the FRP programmer to get aging etc. right by using the time argument trick to make wrong signal use result in a type error. In Grapefruit, a signal is a function from a time *interval* to values where the time interval is denoted by this type argument.
[…]
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;-).
In Grapefruit, you could implement a continous signal which represents an absolute clock. This is because you can make a continuous signal out of any continuous source that can be asked to tell its current value by means of an I/O action. But absolute time isn’t fundamental to Grapefruit. You could think of some totally ordered set representing time and continuous signals being functions from this set to values. But you can only access continuous signals by sampling them using a discrete signal. So you can only get the value of a continous signal at those times where some event occurs. You have the advantage that you can abstract from sampling rates and similar stuff by composing continuous signals. But at some point you have to sample explicitely.
Claus
Best wishes, Wolfgang