> ...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