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

[Stefan Kersten]

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?




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

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

[Don Stewart]

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

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

[Peter Verswyvelen]

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

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

[Thomas Hartman]

I was able to compile and play space invaders on linux. 

Hours of fun for the whole family :)

thomas.





Peter Verswyvelen <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
11/20/2007 06:46 AM
Please respond to
[EMAIL PROTECTED]


To
Don Stewart <[EMAIL PROTECTED]>
cc
Haskell-Cafe 
Subject
Re: [Haskell-cafe] The Yampa Arcade: source code available?






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



---

This e-mail may contain confidential and/or privileged information. If you 
are not the intended recipient (or have received this e-mail in error) 
please notify the sender immediately and destroy this e-mail. Any 
unauthorized copying, disclosure or distribution of the material in this 
e-mail is strictly forbidden.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Paul L]

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

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

[Peter Verswyvelen]

That's very nice to hear! 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
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

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

[Bit Connor]

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