[Haskell-cafe] Tetris

[Conal Elliott]

Hi Peter,

>     First of all Conal, I find all of your work amazingly cool. Do you
have fan list? ;-)

:)

>     Conal Elliott wrote:
> >     Moreover, functional programming makes it easy to have much more
state than imperative programming, namely state over *continuous* time.  The
temporally discrete time imposed by the imperative model is pretty puny in
comparison.  Continuous (or "resolution-independent") time has the same
advantages as continuous space: resource-adaptive, scalable, transformable.
>     Yes, that's true, but isn't that also the problem with FRP? I mean,
most of the papers I'm reading about (A)FRP indicate that no matter how nice
it is to have the continuous time model, to get fine grained control over
execution times and resources, one needs to fall back to the discrete
delta-time approach?

I haven't found that to be the case.  I'd like to understand what specific
implementation issues seem to conflict with continuous time.  Can anyone
help me out?

> And you still need to think about where you have to introduce delays to
avoid infinite loops? I might be wrong, since I don't understand everything
in these papers yet ;-)

There were two places in Fran where timing was a bit delicate to get
termination.  I made sure that reactive behaviors don't change at the moment
of the event occurrence, but rather immediately after it.  You could call it
an "infinitessimal delay".  There was no delta>0.  The other is very
similar: ordinary differential equations (expressed recursively, using
integration).  Again, there was no time delta in the semantics.

I also got the impression that some of the folks at Yale thought it
necessary to add in some kind of (non-infinitessimal) delay, related to
termination, but I don't know why.  Maybe Henrik will comment.

>     About continuous time; it is in fact, not really continuous is it,
since floats are used to approximate time. So the longer your program runs,
the less accurate an absolute time value will become no? Okay, if you use
64-bit floats, you will have to let is run a very long time :-)

Sure.  And yes 64 bits help.  And we could certainly use a bigfloat
representation to get really continuous time (and space).

>     Since nobody replied yet on my question about the future of (A)FRP,
maybe I can ask it again here? What is the future for FRP? Are other
approaches better suitable for reactive applications?

I've been itching to get back into (A)FRP to address some of these issues of
continuous time, as well as modular interaction.  Also toward making a much
more efficient implementation, based mainly on data-driven evaluation.  I've
made some preliminary experiments, described at
http://haskell.org/haskellwiki/DataDriven , used in Phooey, GuiTV, and Eros.

Cheers,  - Conal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071121/8aa08472/attachment.htm