I don't really agree that in Haskell when it comes to simulation a program "just is". That is the idealized story.<div><br></div><div>At least when writing your own simulation engine, in practice you have to deal with operational details such as future unknown values that can block computations; to much laziness can cause hickups in the framerate since unobserved computations build up over time (a bit like sum does) which is why most Yampa simulations I've seen mark all the outputs deep strict (so even the end user needs to know about the operational details); binding to the head of signals and signal recursion causes space and time leaks, and that's why Yampa doesn't provide first signals, which in turn gives problems with inefficiency regarding too much redundant evaluation, etc... </div>
<div><br></div><div><em style="font-style: normal; ">Wolfgang </em>Jeltsch is working on a PhD thesis for Grapefruit in which I hope all problems with FRP will be nicely documented, since currently there doesn't seem to be clear literature that tells the whole story with pros/cons of each framework.</div>
<div><br></div><div>I even believe Luke Palmer abandoned Haskell for doing FRP and started inventing his own language "Dana"; see <a href="http://lukepalmer.wordpress.com/">http://lukepalmer.wordpress.com</a></div>
<div><br></div><div>And of course Conal Elliot's blog outlines some of the problems and beauties of his latest FRP system (Reactive)</div><div><br></div><div>So it's not all sunshine and roses, but that's also what makes it interesting :)</div>
<div><br></div><div>2009/8/19 Maurício CA <span dir="ltr"><<a href="mailto:mauricio.antunes@gmail.com">mauricio.antunes@gmail.com</a>></span></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When I was using C and Python, I used to think of most applications in an<br>
simulation way. I think it's right to say that programs are simulations.<br>
But now I have to change my mind in Haskell, I have to think in a data-flow<br>
way, that is: data in, processing using function composition, data out.<br>
</blockquote>
<br></div>
You have to think there's no in and out, since there's<br>
no state and so no before and after. And no flow, since<br>
time is just an ilusion of users. In Haskell, a program<br>
just "is".<br>
<br>
Sorry, could not resist the Jedi talk...<br>
<br>
Hope you like the language. Best,<br>
Maurício<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>