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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
