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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe