Thanks for the feedback. Unfortunatly the Space Invaders game uses HGL, which is not supported on Windows anymore. Is it supported on Linux? Frag does compile and run on Windows using GHC 6.6.1, so that might be a better starting point. What is the current consensus regarding (A)FRP? Is it a dead end? Are approaches like Modelica http://en.wikipedia.org/wiki/Modelica better suited for the job? From the point of view of a veteran assembly/C++ game hacker like myself, it is funny to see that the same problems popup when doing "reactive programming" in a pure language like Haskell or an imperative language like C++... Recursive dependencies are problematic, be it with signals in FRP or with objects in C++. In videogames using an imperative language, this is often solved by just adding a global "single frame" delay between what is read and what is written. Ugly, but works in many cases. Or a third object is introduced that breaks the recursive dependency between the two problematic objects. If I'm correct, when switching from FRP to AFRP signals (type Signal a = Time -> a) are no first class values anymore, only signal functions (type SF a b = Signal a -> Signal b) are first class. Furthermore the handling of recursive dependencies/feedback is done solely in a loop arrow. I must say it is frustratring. I finally got to understand FRP from the SOE book, only to find out that it is not really the way to go ;-) Now I'm trying to grasp AFRP. It is incredibly interesting stuff, but for a not-so-abstract-thinking-average programmer like me, it is not an obvious task. Maybe *using* AFRP is easier than understanding the inner details... Maybe it would be a good idea for the community if someone (maybe me, if I find the time ;-) to write a very very simple game using AFRP and GHC 6.8.1? Even simpler than the Space Invaders game (which does not work anymore anyway), but which does show dynamic collections and switching? Maybe like Andrew Coppin mentioned, a very simple Tetris clone? Of course, this is not legal, Tetris is copyrighted, but maybe for tutorial purposes it can be allowed :) Don Stewart wrote:

sk:

...

On 19.11.2007, at 19:54, Peter Verswyvelen wrote:

...

I can find the paper, but is the source code for that Space Invaders alike game also available somewhere?

it's included here: http://haskell.org/yampa/afrp-0.4-src.tgz

btw, does anybody know what's the current state of affairs with yampa/ afrp? is the framework still developed further?

Can we get this uploaded to hackage?

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

Just to echo back to the question whether Yampa/AFRP is still being developed, the answer is YES. We are working on an updated version at Yale. But really, we have many choices of doing reactive programming, and AFRP is only one of them. And even for AFRP, there are many choices of combinators and event switch constructs. There is still more research work to be done before we can settle on the interface for next version. I agree that more examples in the line of Space Invaders will serve the purpose of not only illustrating the capability, but also as tutorials to get people started. We'll first clean up existing code and bring it up to date, from which hopefully more examples could be developed. -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale On 11/20/07, Peter Verswyvelen wrote:

Thanks for the feedback. Unfortunatly the Space Invaders game uses HGL, which is not supported on Windows anymore. Is it supported on Linux?

Frag does compile and run on Windows using GHC 6.6.1, so that might be a better starting point.

What is the current consensus regarding (A)FRP? Is it a dead end? Are approaches like Modelica better suited for the job?

...

From the point of view of a veteran assembly/C++ game hacker like myself, it is funny to see that the same problems popup when doing "reactive programming" in a pure language like Haskell or an imperative language like C++... Recursive dependencies are problematic, be it with signals in FRP or with objects in C++. In videogames using an imperative language, this is often solved by just adding a global "single frame" delay between what is read and what is written. Ugly, but works in many cases. Or a third object is introduced that breaks the recursive dependency between the two problematic objects. If I'm correct, when switching from FRP to AFRP signals (type Signal a = Time -> a) are no first class values anymore, only signal functions (type SF a b = Signal a -> Signal b) are first class. Furthermore the handling of recursive dependencies/feedback is done solely in a loop arrow.

I must say it is frustratring. I finally got to understand FRP from the SOE book, only to find out that it is not really the way to go ;-) Now I'm trying to grasp AFRP. It is incredibly interesting stuff, but for a not-so-abstract-thinking-average programmer like me, it is not an obvious task. Maybe *using* AFRP is easier than understanding the inner details...

Maybe it would be a good idea for the community if someone (maybe me, if I find the time ;-) to write a very very simple game using AFRP and GHC 6.8.1? Even simpler than the Space Invaders game (which does not work anymore anyway), but which does show dynamic collections and switching? Maybe like Andrew Coppin mentioned, a very simple Tetris clone? Of course, this is not legal, Tetris is copyrighted, but maybe for tutorial purposes it can be allowed :)

Don Stewart wrote: sk:

On 19.11.2007, at 19:54, Peter Verswyvelen wrote:

I can find the paper, but is the source code for that Space Invaders alike game also available somewhere?

it's included here: http://haskell.org/yampa/afrp-0.4-src.tgz

btw, does anybody know what's the current state of affairs with yampa/ afrp? is the framework still developed further?

Can we get this uploaded to hackage?

-- Don _______________________________________________ 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

I am also happy to hear this. When will the new version be released? Thanks, Bit On Nov 21, 2007 7:11 PM, Paul L wrote:

Just to echo back to the question whether Yampa/AFRP is still being developed, the answer is YES. We are working on an updated version at Yale.

But really, we have many choices of doing reactive programming, and AFRP is only one of them. And even for AFRP, there are many choices of combinators and event switch constructs. There is still more research work to be done before we can settle on the interface for next version.

I agree that more examples in the line of Space Invaders will serve the purpose of not only illustrating the capability, but also as tutorials to get people started. We'll first clean up existing code and bring it up to date, from which hopefully more examples could be developed.

-- Regards, Paul Liu

Yale Haskell Group http://www.haskell.org/yale

On 11/20/07, Peter Verswyvelen wrote:

...

Thanks for the feedback. Unfortunatly the Space Invaders game uses HGL, which is not supported on Windows anymore. Is it supported on Linux?

Frag does compile and run on Windows using GHC 6.6.1, so that might be a better starting point.

What is the current consensus regarding (A)FRP? Is it a dead end? Are approaches like Modelica better suited for the job?

...

From the point of view of a veteran assembly/C++ game hacker like myself, it is funny to see that the same problems popup when doing "reactive programming" in a pure language like Haskell or an imperative language like C++... Recursive dependencies are problematic, be it with signals in FRP or with objects in C++. In videogames using an imperative language, this is often solved by just adding a global "single frame" delay between what is read and what is written. Ugly, but works in many cases. Or a third object is introduced that breaks the recursive dependency between the two problematic objects. If I'm correct, when switching from FRP to AFRP signals (type Signal a = Time -> a) are no first class values anymore, only signal functions (type SF a b = Signal a -> Signal b) are first class. Furthermore the handling of recursive dependencies/feedback is done solely in a loop arrow.

I must say it is frustratring. I finally got to understand FRP from the SOE book, only to find out that it is not really the way to go ;-) Now I'm trying to grasp AFRP. It is incredibly interesting stuff, but for a not-so-abstract-thinking-average programmer like me, it is not an obvious task. Maybe *using* AFRP is easier than understanding the inner details...

Maybe it would be a good idea for the community if someone (maybe me, if I find the time ;-) to write a very very simple game using AFRP and GHC 6.8.1? Even simpler than the Space Invaders game (which does not work anymore anyway), but which does show dynamic collections and switching? Maybe like Andrew Coppin mentioned, a very simple Tetris clone? Of course, this is not legal, Tetris is copyrighted, but maybe for tutorial purposes it can be allowed :)

Don Stewart wrote: sk:

On 19.11.2007, at 19:54, Peter Verswyvelen wrote:

I can find the paper, but is the source code for that Space Invaders alike game also available somewhere?

it's included here: http://haskell.org/yampa/afrp-0.4-src.tgz

btw, does anybody know what's the current state of affairs with yampa/ afrp? is the framework still developed further?

Can we get this uploaded to hackage?

-- Don _______________________________________________ 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