> ...Are hereby presented at: > http://www.ee.bgu.ac.il/~noamle/_downloads/gaccum.pdf > > Comments are more than welcome. > (P.S Thanks to a whole bunch of people at #haskell for educating me about > this, but most notably Conal Elliott)
Well, my impression is that trying to unite events and behaviours in this manner is not the solution we're looking for. If you follow the WWRD principle, you have to forget about events as fundamental building blocks, because the concept of event is an abstraction over continuous phenomena. Reality has a trivial solution: throw extreme parallelism at the problem, set an extremely high sampling rate and shamelessly 'recalculate' unchanging parts of the system all the time (which is exactly why you don't want to use Yampa or Elerea for GUI programming: they are pull-based, so they'll keep the CPU churning even in the absence of events; note also that both solve the problem of unlimited access to the past). In this framework, events can only be introduced as high-level abstractions that require much more computational power than what would seem necessary. It is a bit like using a large and complex neural network to perform basic arithmetic. Also, if you think about the applicative, monad etc. type class morphisms, you'll see that what makes sense for behaviours is completely useless for events. For instance, the applicative instance for behaviours (time functions) gives us a neat point-wise function application. However, if you define events as functions that are undefined almost everywhere, point-wise application of two events is only defined at the times where both events yield a value simultaneously. Same for monads: they capture the act of sampling for behaviours, but they can't do much for temporal values that are mostly undefined if interpreted as the reader monad. This suggests that events and behaviours have a different nature. Either only behaviours have a meaningful monad instance, or their meaningful monad instances are different. The unified system you're describing very much reminds me of Lucid Synchrone, if we think of behaviours as signals synchronised to the base clock, while events as signals with a slower clock. It might be interesting to think about how clock calculus interacts with the type class instances. However, that still doesn't say anything about the fact that the set of operations meaningful for behaviours and events are different, with only some overlap. Gergely -- http://www.fastmail.fm - Does exactly what it says on the tin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe