Am Dienstag, 21. April 2009 17:18 schrieb Patai Gergely: > > What about evaluation time? If I remember correctly, the values > > of signals depend on the time when the signal expressions are > > evaluated. So evaluating them multiple times might lead to > > different behavior. Is this correct? > > It is. However, there is really only one construct that needs extra care > here: the latcher. All the others create top-level nodes that get > evaluated just once during the first attempt to sample the output of the > network. Therefore, duplication and merging of identical expressions > only affects the performance unless they are hidden in the input signal > of a latcher.
But isn’t the latter a fundamental problem? To make things a bit more concrete, look at the following code snippet: > time :: Signal DTime > time = stateful 0 (+) > > timeSwitching :: Signal Bool -> Signal DTime > timeSwitching control = latcher time control (pure time) If the time signal is evaluated only once then for any signal c, timeSwitching c should be equivalent to time. But what if I replace time by stateful 0 (+) in the definition of timeSwitching? If stateful 0 (+) is evaluated everytime a switch occurs then timeSwitching would always switch back to time 0. So one first has to answer the question what the intended semantics should be. Should signals start at the beginning or should they start every time they are switched into? 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.) 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. Maybe I just misunderstood something, so please correct me if I’m wrong. Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
