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? 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 ;-)

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 :-)

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?

About Monadius, yes, I also think it's very nice. It is based on IMO one of the greatest videogames ever, Gradius (aka Nemesis). You don't want to know how much money I put in those Konami arcade machines ;-) But Monadius just mimics the imperative discrete time approach, which of course, does work, since 99.99% or so of the videogames on the market use this approach. Monadius is really easy to understand for Haskell newbies, and it shows that you actually can make a nice game without using incredibly tricky abstractions :-) However, I found that as soon as I try to make my own combinators, to piece several "reactive objects" together, I always seem to mimic FRP, and finally AFRP.

Cheers,
Peter

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.

On Nov 20, 2007 4:11 PM, Lennart Augustsson <lennart@augustsson.net> wrote:

I implemented Tetris in LML long before Haskell existed.
It was text based, but looked good with a custom font. :)

Haskell has no problem with state, it's just explicit.

-- Lennart

On Nov 19, 2007 9:25 PM, Andrew Coppin <andrewcoppin@btinternet.com> wrote:

If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make
a nice example program...)

I'm particularly interested to know

1. How exactly would you do the graphical components? (Presumably
there's some deep trickery with Gtk2hs that can draw free-form stuff
like this.)

2. How do you implement a program that is fundamentally about state
mutation in a programming language which abhors state mutation?

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
  