[Haskell-cafe] Re: A few ideas about FRP and arbitrary access in time

[sinelaw]

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