[Haskell-cafe] The Yampa Arcade: source code available?

Peter Verswyvelen bf3 at telenet.be
Wed Nov 21 12:58:23 EST 2007

That's very nice to hear! 

-----Original Message-----
From: haskell-cafe-bounces at haskell.org
[mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Paul L
Sent: Wednesday, November 21, 2007 6:11 PM
To: Haskell-Cafe
Subject: Re: [Haskell-cafe] The Yampa Arcade: source code available?

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

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

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

Paul Liu

Yale Haskell Group

On 11/20/07, Peter Verswyvelen <bf3 at telenet.be> 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
> it is funny to see that the same problems popup when doing "reactive
> programming" in a pure language like Haskell or an imperative language
> C++... Recursive dependencies are problematic, be it with signals in FRP
> 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
> (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.
> 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
> 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
> find the time ;-) to write a very very simple game using AFRP and GHC
> 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
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
Haskell-Cafe mailing list
Haskell-Cafe at haskell.org

More information about the Haskell-Cafe mailing list