<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
First of all Conal, I find all of your work amazingly cool. Do you have
fan list? <span class="moz-smiley-s3"><span> ;-) </span></span><br>
<br>
Conal Elliott wrote:
<blockquote
 cite="mid:ea8ae9fb0711201827t15721f05y47c5bd38ddb0c52f@mail.gmail.com"
 type="cite">Moreover,
functional programming makes it easy to have much more state than
imperative programming, namely state over *continuous* time.&nbsp; The
temporally discrete time imposed by the imperative model is pretty puny
in comparison.&nbsp; Continuous (or "resolution-independent") time has the
same advantages as continuous space: resource-adaptive, scalable,
transformable.
  <br>
</blockquote>
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 ;-)<br>
<br>
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 :-)
<br>
<br>
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?<br>
<br>
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 :-)&nbsp; 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. <br>
<br>
Cheers,<br>
Peter<br>
<br>
Conal Elliott wrote:
<blockquote
 cite="mid:ea8ae9fb0711201827t15721f05y47c5bd38ddb0c52f@mail.gmail.com"
 type="cite">Moreover, functional programming makes it easy to have
much more state than imperative programming, namely state over
*continuous* time.&nbsp; The temporally discrete time imposed by the
imperative model is pretty puny in comparison.&nbsp; Continuous (or
"resolution-independent") time has the same advantages as continuous
space: resource-adaptive, scalable, transformable.
  <br>
  <br>
  <div class="gmail_quote">On Nov 20, 2007 4:11 PM, Lennart Augustsson
&lt;<a moz-do-not-send="true" href="mailto:lennart@augustsson.net">lennart@augustsson.net</a>&gt;
wrote:<br>
  <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
implemented Tetris in LML long before Haskell existed.<br>
It was text based, but looked good with a custom font. :)<br>
    <br>
Haskell has no problem with state, it's just explicit.<br>
    <font color="#888888"><br>
&nbsp; -- Lennart
    <br>
    <br>
    </font>
    <div class="gmail_quote">
    <div class="Ih2E3d">On Nov 19, 2007 9:25 PM, Andrew Coppin &lt;<a
 moz-do-not-send="true" href="mailto:andrewcoppin@btinternet.com"
 target="_blank">andrewcoppin@btinternet.com</a>&gt; wrote:<br>
    </div>
    <div>
    <div class="Wj3C7c">
    <blockquote class="gmail_quote"
 style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">If
you were going to implement Tetris in Haskell, how would you do it?<br>
      <br>
(For that matter, has anybody already *done* it? It would probably make<br>
a nice example program...)<br>
      <br>
I'm particularly interested to know
      <br>
      <br>
1. How exactly would you do the graphical components? (Presumably<br>
there's some deep trickery with Gtk2hs that can draw free-form stuff<br>
like this.)<br>
      <br>
2. How do you implement a program that is fundamentally about state
      <br>
mutation in a programming language which abhors state mutation?<br>
      <br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
      <a moz-do-not-send="true" href="mailto:Haskell-Cafe@haskell.org"
 target="_blank">Haskell-Cafe@haskell.org
      </a><br>
      <a moz-do-not-send="true"
 href="http://www.haskell.org/mailman/listinfo/haskell-cafe"
 target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
    </blockquote>
    </div>
    </div>
    </div>
    <br>
    <br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
    <a moz-do-not-send="true" href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
    <a moz-do-not-send="true"
 href="http://www.haskell.org/mailman/listinfo/haskell-cafe"
 target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
    <br>
  </blockquote>
  </div>
  <br>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Haskell-Cafe mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a>
  </pre>
</blockquote>
<br>
</body>
</html>