> 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.
I'm not sure I want to follow WWRD all the way. I do want events, for example mouse clicks (for which there doesn't seem to be any logical behavior representation). As you note the pull-based approach does a lot more work in those cases than seems necessary. In any case, what I'm discussing in that report is mostly centered on the continuous-time values, so I'm more concerned with what we call behaviors. The question is how to model memory-full operations with point-wise operations. The only answer I've found for that in the Yampa framework is feedback with "pre", whose semantics seem to be the value after a "very short delay". This doesn't seem to hold water, when we really want to take the idea of continuous time seriously. > 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. Right. You'll agree that it would be nice to have a general approach? How will that work? That's what I'd like to find out. > 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. Interesting points, I didn't consider that at all when writing that report. I'd like things to be unified, so maybe playing with the idea of a total function to 'Maybe a' for events is the right direction. I think this was already explored by some FRP incarnations, but I don't recall what came out of it. > 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. But isn't Lucid Synchrone essentially discrete-timed? Also, events shouldn't be semantically constrained to multiples of some basic clock, they are defined over continuous time. Regarding the type classes - again I haven't thought in that direction much. > > Gergely P.S Thanks for the feedback! _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe