Am Mittwoch, 22. April 2009 16:00 schrieb Patai Gergely:
This also means that if you want to restart a signal without external dependencies using a latcher, you have to inject some bogus dependency to prevent memoisation. If the new signal depends on some others, latching should behave intuitively.
So does this mean that whether a signal is started at the beginning or at switching time depends on what dependencies the signal has?
Implementing the first semantics is difficult since the system would have to know what signals will be used later. I think this is impossible in general because of undecidability issues. (Grapefruit's approach is to force the user to specify what signals are used later.)
Do you have a compact use case that demonstrates this problem?
Maybe it’s not directly undecidability. What I have in mind is the following: Say, you have a complicated function f :: DTime -> Bool and two signals s1 and s2. Then you form the following signal: (\t -> if f t then s1 else s2) <$> time. In order to know what signals should be started at the beginning, you would have to know whether f will ever yield False or True so that you know which of s1 and s2 will be needed at some point.
Implementing the second semantics would require a single signal having possibly different values when started at different times. This in turn would disallow caching of signal values in mutable variables.
Or at least it would require deep copying some initial snapshot at every restart. But this only applies to completely self-contained signals, since anything that depends on the outer world cannot be restarted by definition.
Why not? You could have a signal which always yields the last key press. This clearly depends on the outer world. Then you construct another signal out of this which counts how often a certain key was pressed. If this latter signal is evaluated several times, it could start counting from different times on, couldn’t it? Best wishes, Wolfgang