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

Patai Gergely patai_gergely at fastmail.fm
Fri Mar 5 08:49:32 EST 2010


> 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.
Events are indispensable for practically all applications, even those
that have continuous output, so leaving them out would be no option. I
only did so for Elerea to be able to quickly get a working system
running, so I can actually experiment with application-side design. But
yeah, it can't be used for serious purposes without some support for
events.

> 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.
I think it would help if you tried to solve more specific problems first
and see what common structure you can factor out from the solutions.
It's easy to get into a dead end if you go for the big picture right
away.

> 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.
And I do hope you'll manage to find a useful result. My intuition says,
however, that looking for a sensible interface between events and
behaviours is more fruitful than trying to unify these two notions. The
reason is the difference in TCMs, as noted previously.

> 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.
Yes, that's the Yampa way. The problem is that in this case you'll need
an awkward operator to refer to 'the time of last defined point'.

> 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.
Of course, it's more like a possible model for operational semantics (I
know you're interested in denotation, but inspiration can come from
anywhere). I just thought that clock calculus might be an interesting
topic to throw into the hat.

Gergely

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free



More information about the Haskell-Cafe mailing list