Tetris

Andrew Coppin

19 Nov 2007 19 Nov '07

4:25 p.m.

If you were going to implement Tetris in Haskell, how would you do it? (For that matter, has anybody already *done* it? It would probably make a nice example program...) I'm particularly interested to know 1. How exactly would you do the graphical components? (Presumably there's some deep trickery with Gtk2hs that can draw free-form stuff like this.) 2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

Show replies by date

Don Stewart

19 Nov 19 Nov

5:12 p.m.

andrewcoppin:

...

If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

http://haskell.org/haskellwiki/Applications_and_libraries/Games ASCII tetris http://web.comlab.ox.ac.uk/oucl/work/ian.lynagh/Hetris/ OpenGL or Gtk2Hs seem the best options.

...

2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

Its not clear games are fundamentally about mutation, anymore than, say, window managers are. State we do with monads. Check the thesis on Frag for a pure approach, or just use StateT IO. -- Don

Jon Harrop

20 Nov 20 Nov

5:46 a.m.

On Monday 19 November 2007 22:12, Don Stewart wrote:

...

Check the thesis on Frag for a pure approach, or just use StateT IO.

Has Frag been fixed to work on x86-64? -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

Don Stewart

1:57 p.m.

jon:

...

On Monday 19 November 2007 22:12, Don Stewart wrote:

...
Check the thesis on Frag for a pure approach, or just use StateT IO.

Has Frag been fixed to work on x86-64?

Not that I'm aware of -- it lacks a game head maintainer

Mathieu Boespflug

10:02 a.m.

...

...
2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

Its not clear games are fundamentally about mutation, anymore than, say, window managers are. State we do with monads.

Indeed. Ignoring the concept of a monad for the moment, you could think of your tetris engine as a function mapping a stream of user inputs to a stream of resulting states. ie data Action = None | Rotate | Left | Right | Down data State = ... tetris :: [Action] -> [State] tetris = scanl step step :: State -> Action -> State step = ... where State would probably model the playing grid and where all the squares are, including the current position of the falling piece. Remember that scanl has signature equivalent to scanl :: (s -> a -> s) -> s -> [a] -> [s] Given some function f on states, an (infinite) list of actions and an initial state, it will return an (infinite) list of states determined by f and the list of actions. The list of inputs from the user can be gotten using the 'getContents' function, for instance. The 'tetris' function will yield new states only as new inputs from the user are available; that's the magic of lazyness. So you could then take this list of states and display each to the user, as they become available. Your 'main' function would look something like: main = do s <- getContents lets actions = parseActions s mapM_ drawTetrisGrid (tetris actions) where drawTetrisGrid renders a state to the screen: drawTetrisGrid :: State -> IO () Some people think getContents is evil, for reasons I won't go into, in which case another solution would probably involve a monad looking like StateT IO, as Dons suggests. Either way, it really isn't a problem to implement tetris in a functional style, and Haskell is certainly up to the task! Hope this helps, Mathieu

Andrew Coppin

2:27 p.m.

Don Stewart wrote:

...

andrewcoppin:

...
If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

http://haskell.org/haskellwiki/Applications_and_libraries/Games

ASCII tetris http://web.comlab.ox.ac.uk/oucl/work/ian.lynagh/Hetris/

OpenGL or Gtk2Hs seem the best options.

OK, well I'll have a go at seeing if I can put something together with Gtk2hs. (Nitpick: Don't you need Gtk2hs in order to *use* OpenGL? I mean, you have to open a window to render into somehow, and that's outside the OpenGL standard...)

...

...
2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

Its not clear games are fundamentally about mutation, anymore than, say, window managers are. State we do with monads.

Hmm. On reflection, Tetris is probably a poor example of this. It has a fairly small, simple state that you can easily manipulate purely functionally. But if you imagine, say, an FPS game, where you have (possibly multiple) players running around, NPCs running after them, possibly a nontrivial physics engine, possibly a nontrivial AI system, possibly nontrivial scripted sequences happening... how do you *do* all that in Haskell?

...

Check the thesis on Frag for a pure approach, or just use StateT IO.

Indeed, Frag is interesting because it conclusively demonstrates that this can be done in Haskell (by doing it!) However, all the material I've read about it is unfortunately utterly incomprehensible. I still have no idea how it is possible to build such a highly interactive system in a language which strongly discourages interactivity...

Radosław Grzanka

2:57 p.m.

Hi,

...

(Nitpick: Don't you need Gtk2hs in order to *use* OpenGL? I mean, you have to open a window to render into somehow, and that's outside the OpenGL standard...)

You have GLUT library for just that: http://www.haskell.org/ghc/docs/latest/html/libraries/GLUT-2.1.1.1/Graphics-... Cheers, Radek. -- Codeside: http://codeside.org/ Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/

Stefan O'Rear

2:58 p.m.

On Tue, Nov 20, 2007 at 07:27:48PM +0000, Andrew Coppin wrote:

...

(Nitpick: Don't you need Gtk2hs in order to *use* OpenGL? I mean, you have to open a window to render into somehow, and that's outside the OpenGL standard...)

You need *something*, but it need not be Gtk. GLUT and GLX will also work, and at least the former has a Haskell binding. Stefan

Andrew Coppin

3 p.m.

Stefan O'Rear wrote:

...

On Tue, Nov 20, 2007 at 07:27:48PM +0000, Andrew Coppin wrote:

...
(Nitpick: Don't you need Gtk2hs in order to *use* OpenGL? I mean, you have to open a window to render into somehow, and that's outside the OpenGL standard...)

You need *something*, but it need not be Gtk.

Correct. That's when I meant to say.

...

GLUT and GLX will also work, and at least the former has a Haskell binding.

As far as I'm aware, GLUT isn't available for Windows. (Or rather, I tried it once, and it wasn't happy at all. And after some Google searching, I found it's not around any more.)

Bit Connor

3:23 p.m.

...

As far as I'm aware, GLUT isn't available for Windows. (Or rather, I tried it once, and it wasn't happy at all. And after some Google searching, I found it's not around any more.)

GLUT should work fine on windows, but another alternative is SDL, which works on Windows, GNU/Linux, and Mac The haskell bindings are here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-0.5.1

Radosław Grzanka

3:53 p.m.

2007/11/20, Bit Connor :

...

...
As far as I'm aware, GLUT isn't available for Windows. (Or rather, I tried it once, and it wasn't happy at all. And after some Google searching, I found it's not around any more.)

GLUT should work fine on windows, but another alternative is SDL, which works on Windows, GNU/Linux, and Mac

The haskell bindings are here:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-0.5.1

Last time I checked it I couldn't compile it. But I see the version number has gone up much since that! Cool. I will give it a shot! Thanks, Radek. -- Codeside: http://codeside.org/ Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/

Andrew Coppin

21 Nov 21 Nov

2:46 p.m.

New subject: libSDL [Tetris]

Radosław Grzanka wrote:

...

2007/11/20, Bit Connor :

...
GLUT should work fine on windows, but another alternative is SDL, which works on Windows, GNU/Linux, and Mac

The haskell bindings are here:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SDL-0.5.1

Last time I checked it I couldn't compile it. But I see the version number has gone up much since that! Cool. I will give it a shot!

I'm pretty sure I've tried to install this before and failed. Let me go check... ...yep, configure fails because it can't find "sh". (Again.) It's a pitty - it looks like you can do sound with SDL, and that's something which greatly interests me.

Jorge Marques Pelizzoni

3:53 p.m.

New subject: libSDL [Tetris]

Andrew Coppin escreveu:

...

...yep, configure fails because it can't find "sh". (Again.)

You are probably not using cygwin, are you? I mean, it includes "sh" and should get you going. Just make sure to check all you need in the cygwin setup. Cheers, Jorge.

Andrew Coppin

3:59 p.m.

New subject: libSDL [Tetris]

Jorge Marques Pelizzoni wrote:

...

Andrew Coppin escreveu:

...
...yep, configure fails because it can't find "sh". (Again.)

You are probably not using cygwin, are you? I mean, it includes "sh" and should get you going. Just make sure to check all you need in the cygwin setup.

I'm rather loathed to install a Unix emulator just so I can install things from Hackage. By the way, it turns out that SDL at least comes with a little text file explaining how to build it on Windows. (I overlooked this the first time.) Sadly, after following the instructions I still can't build it. The changes it told me to make didn't seem to have any effect. (And manually editing configuration files and C headers isn't my idea of a good time anyway...) Out of curiosity, is there a reason I'm trying to compile the code myself in the first place? Is it just because that's "the Unix way", or is there some deep reason why we can't just download prebuilt binaries?

Bit Connor

22 Nov 22 Nov

10:32 a.m.

New subject: libSDL [Tetris]

Hello Andrew,

...

...
...
...yep, configure fails because it can't find "sh". (Again.)

This error can safely be ignored on windows.

...

I'm rather loathed to install a Unix emulator just so I can install things from Hackage.

cygwin is not required to build hsSDL on windows.

...

By the way, it turns out that SDL at least comes with a little text file explaining how to build it on Windows. (I overlooked this the first time.) Sadly, after following the instructions I still can't build it. The changes it told me to make didn't seem to have any effect. (And manually editing configuration files and C headers isn't my idea of a good time anyway...)

What error are you getting? The next version of hsSDL (or current darcs) will not require editing of C headers. Editing the cabal config file is necessary so that the SDL include files and libs can be found.

...

Out of curiosity, is there a reason I'm trying to compile the code myself in the first place? Is it just because that's "the Unix way", or is there some deep reason why we can't just download prebuilt binaries?

I am in favour of the idea of providing prebuilt binaries. Do you think something like the gtk2hs windows installer would be good? Thanks, Bit

Andrew Coppin

2:39 p.m.

New subject: libSDL [Tetris]

Bit Connor wrote:

...

Hello Andrew,

...
...
...
...yep, configure fails because it can't find "sh". (Again.)

This error can safely be ignored on windows.

Apparently so. (A bit confusing then, no?)

...

...
I'm rather loathed to install a Unix emulator just so I can install things from Hackage.

cygwin is not required to build hsSDL on windows.

Glad to hear it. :-)

...

...
By the way, it turns out that SDL at least comes with a little text file explaining how to build it on Windows. (I overlooked this the first time.) Sadly, after following the instructions I still can't build it. The changes it told me to make didn't seem to have any effect. (And manually editing configuration files and C headers isn't my idea of a good time anyway...)

What error are you getting?

Many pages of them. Mostly about undefined symbols. I've deleted all the files now; I'll maybe have another go at it later so I can tell you the exact error.

...

The next version of hsSDL (or current darcs) will not require editing of C headers.

Good. :-)

...

Editing the cabal config file is necessary so that the SDL include files and libs can be found.

...because Windows uses DLLs instead of [whatever it is that Unix does]?

...

...
Out of curiosity, is there a reason I'm trying to compile the code myself in the first place? Is it just because that's "the Unix way", or is there some deep reason why we can't just download prebuilt binaries?

I am in favour of the idea of providing prebuilt binaries. Do you think something like the gtk2hs windows installer would be good?

Gtk2hs is certainly drop-dead easy to install, no doubt about that. (Modulo some tricky path fiddling if you install Glade seperately as well... but that's no fault of the Haskell package.) Personally, given how tricky it generally is to build *most* things from source code (you have to have all the right tools to do it), I'd prefer to see *all* packages available in binary form. However, I guess the number of packages and possible target platforms makes this prohibitive...

Bit Connor

5:53 p.m.

New subject: libSDL [Tetris]

On Nov 22, 2007 9:39 PM, Andrew Coppin wrote:

...

...
Editing the cabal config file is necessary so that the SDL include files and libs can be found.

...because Windows uses DLLs instead of [whatever it is that Unix does]?

The reason is that on Unix, there are standard location for header files and libraries. On windows, they can be anywhere, and in the case of SDL, they are inside the directory where SDL was installed.

...

...
...
Out of curiosity, is there a reason I'm trying to compile the code myself in the first place? Is it just because that's "the Unix way", or is there some deep reason why we can't just download prebuilt binaries?

I am in favour of the idea of providing prebuilt binaries. Do you think something like the gtk2hs windows installer would be good?

Gtk2hs is certainly drop-dead easy to install, no doubt about that. (Modulo some tricky path fiddling if you install Glade seperately as well... but that's no fault of the Haskell package.)

Personally, given how tricky it generally is to build *most* things from source code (you have to have all the right tools to do it), I'd prefer to see *all* packages available in binary form. However, I guess the number of packages and possible target platforms makes this prohibitive...

On GNU/Linux it is usually not tricky at all to build things from source, and a lot of people prefer it over installing binaries. I do agree that binary packages should be available for windows.

Jules Bean

21 Nov 21 Nov

2:06 a.m.

Andrew Coppin wrote:

...

...
GLUT and GLX will also work, and at least the former has a Haskell binding.

As far as I'm aware, GLUT isn't available for Windows. (Or rather, I tried it once, and it wasn't happy at all. And after some Google searching, I found it's not around any more.)

As far as I'm aware, all GL implementations come with a GLUT implementation. It doesn't give you a very sophisticated UI - hardly anything beyond the ability to open new windows - but it does work, it's simple, and it's cross platform. Jules

Jon Harrop

9:27 a.m.

On Wednesday 21 November 2007 07:06, Jules Bean wrote:

...

As far as I'm aware, all GL implementations come with a GLUT implementation.

No: GL is typically installed with your video card drivers and glut must be installed as a separate package. On Linux, package managers handle this transparently and most people have freeglut installed (there is also openglut and the original glut). I'm not sure about Mac OS X but I suspect it also bundles some kind of glut. The last time I looked at Windows it provided only minimal support for GL and no glut. You can install glut on a Windows box but you have to do it manually.

...

It doesn't give you a very sophisticated UI - hardly anything beyond the ability to open new windows - but it does work, it's simple, and it's cross platform.

Yes. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

Peter Verswyvelen

10 a.m.

Yes indeed, and various implementations of GLUT on Windows have different quirks. The biggest lack of GLUT is its inability to load images... IMHO if you want to do OpenGL with Haskell, it's best to start with Gtk2HS anyway, which has all the support needed. Last time I checked the SDL binding did not work properly on Windows when using GHCi. Another nice library that works well is GLFW, which SOE uses. See http://www.haskell.org/soe. It had some quirks on Windows, but I reported these and send over some patches, and it seems they are incorporated in the latest version (in a much cleaner way than my original patches ;-) It also runs more smoothly since it now uses GLFW's high resolution timer. It only lacks support for fonts, but it can load images, so creating a bitmap font should not be too difficult. Cheers, Peter Jon Harrop wrote:

...

On Wednesday 21 November 2007 07:06, Jules Bean wrote:

...
As far as I'm aware, all GL implementations come with a GLUT implementation.

No: GL is typically installed with your video card drivers and glut must be installed as a separate package. On Linux, package managers handle this transparently and most people have freeglut installed (there is also openglut and the original glut). I'm not sure about Mac OS X but I suspect it also bundles some kind of glut. The last time I looked at Windows it provided only minimal support for GL and no glut. You can install glut on a Windows box but you have to do it manually.

...
It doesn't give you a very sophisticated UI - hardly anything beyond the ability to open new windows - but it does work, it's simple, and it's cross platform.

Yes.

Jules Bean

10:26 a.m.

Peter Verswyvelen wrote:

...

Yes indeed, and various implementations of GLUT on Windows have different quirks.

The biggest lack of GLUT is its inability to load images...

IMHO if you want to do OpenGL with Haskell, it's best to start with Gtk2HS anyway, which has all the support needed.

..at the cost of being less portable, since it doesn't run "natively" on OSX, requiring the X layer which not all users will have installed. Swings and roundabouts. OSX-native Gtk is not that far away though. But, that's certainly one of the reasons I'm using plain GLUT at the moment. Jules

Peter Verswyvelen

11:04 a.m.

Well in that case, GLFW seems to run fine on OSX. See http://glfw.sourceforge.net http://glfw.sourceforge.net/ GLUT is portable but has many different implementations. I already had a couple of nasty bugs using it (different keyboard handling, incorrect joystick support, etc). So it's best to always include the GLUT library that was used when you did your testing Jules Bean wrote:

...

..at the cost of being less portable, since it doesn't run "natively" on OSX, requiring the X layer which not all users will have installed. Swings and roundabouts.

OSX-native Gtk is not that far away though.

But, that's certainly one of the reasons I'm using plain GLUT at the moment.

Jules

Conal Elliott

11:10 a.m.

I've just started using OpenGL with wxHaskell, which is my favorite of the Haskell GUI toolkits. (I like elegant interfaces.) So far, so good. If anyone else is using that combination, I'd love to hear about it. On Nov 21, 2007 8:04 AM, Peter Verswyvelen wrote:

...

Well in that case, GLFW seems to run fine on OSX. See http://glfw.sourceforge.net

GLUT is portable but has many different implementations. I already had a couple of nasty bugs using it (different keyboard handling, incorrect joystick support, etc). So it's best to always include the GLUT library that was used when you did your testing

Jules Bean wrote:

..at the cost of being less portable, since it doesn't run "natively" on OSX, requiring the X layer which not all users will have installed. Swings and roundabouts.

OSX-native Gtk is not that far away though.

But, that's certainly one of the reasons I'm using plain GLUT at the moment.

Jules

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

Peter Verswyvelen

11:44 a.m.

New subject: wxHaskell / Proxima (was Tetris)

Ouch, I didn't even look at wxHaskell yet... Should do so then asap. Talking about wxHaskell, one of the applications shown on the website is Proxima. I've been looking for something like that for a long time (combined structural and freestyle editing). The screenshot http://wxhaskell.sourceforge.net/images/proxima-mac.png seems to imply that it supports Haskell. Anyone has experience with that? Conal Elliott wrote:

...

I've just started using OpenGL with wxHaskell, which is my favorite of the Haskell GUI toolkits. (I like elegant interfaces.) So far, so good. If anyone else is using that combination, I'd love to hear about it.

Radosław Grzanka

1:25 p.m.

2007/11/21, Conal Elliott :

...

I've just started using OpenGL with wxHaskell, which is my favorite of the Haskell GUI toolkits. (I like elegant interfaces.) So far, so good. If anyone else is using that combination, I'd love to hear about it.

There are bindings for wxWidgets for Haskell? Bring it on! Is there any GUI building application like Glade for Gtk? Cheers, Radek. -- Codeside: http://codeside.org/ Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/

Andrew Coppin

2:40 p.m.

New subject: wxHaskell [was Tetris]

Radosław Grzanka wrote:

...

2007/11/21, Conal Elliott :

...
I've just started using OpenGL with wxHaskell, which is my favorite of the Haskell GUI toolkits. (I like elegant interfaces.) So far, so good. If anyone else is using that combination, I'd love to hear about it.

There are bindings for wxWidgets for Haskell? Bring it on! Is there any GUI building application like Glade for Gtk?

Doesn't that go through Eiffel first or something strange? I admit I haven't tried it personally, but I'm told getting wxHaskell to build is a tad tricky, and the code hasn't been maintained in a long time. (Isn't Fooey based on it?)

Conal Elliott

5:02 p.m.

New subject: wxHaskell [was Tetris]

...

Doesn't that go through Eiffel first or something strange?

Not at run-time. I think Daan leveraged the Eiffel bindings in automatically generating part of the Haskell bindings.

...

I admit I haven't tried it personally, but I'm told getting wxHaskell to build is a tad tricky, and the code hasn't been maintained in a long time. (Isn't Fooey based on it?)

I think wxHaskell is somewhat maintained but could definitely use more attention. I was delighted to hear recently from Daan that he intends to pick up maintenance again. It really is tastefully designed, as imperative interfaces go. I also heard from Duncan that he intends to work on giving gtk2hs a more elegant layering. Phooey, GuiTV, and Eros are all built on wxHaskell. (See Haskell wiki pages.) Sean Seefried's Pan implementation is also, and uses OpenGL. Cheers, - Conal On Nov 21, 2007 11:40 AM, Andrew Coppin wrote:

...

...
2007/11/21, Conal Elliott :

...
I've just started using OpenGL with wxHaskell, which is my favorite of

Radosław Grzanka wrote: the

...
...
Haskell GUI toolkits. (I like elegant interfaces.) So far, so good. If anyone else is using that combination, I'd love to hear about it.

There are bindings for wxWidgets for Haskell? Bring it on! Is there any GUI building application like Glade for Gtk?

Doesn't that go through Eiffel first or something strange?

I admit I haven't tried it personally, but I'm told getting wxHaskell to build is a tad tricky, and the code hasn't been maintained in a long time. (Isn't Fooey based on it?)

Bit Connor

22 Nov 22 Nov

11:31 a.m.

On Nov 21, 2007 5:00 PM, Peter Verswyvelen wrote:

...

Last time I checked the SDL binding did not work properly on Windows when using GHCi.

The next version of hsSDL (current darcs) has documentation that explains how to get ghci working. The trick is to make copies of the SDL.dll, since for some reason the way hsSDL is built through cabal, ghci looks for this dll under 2 additional names.

Sebastian Sylvan

19 Nov 19 Nov

5:23 p.m.

On Nov 19, 2007 9:25 PM, Andrew Coppin wrote:

...

If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

I'm particularly interested to know

1. How exactly would you do the graphical components? (Presumably there's some deep trickery with Gtk2hs that can draw free-form stuff like this.)

2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

It's not really fundamentally about state mutation. The only "state" you're mutating is when you're actually taking the game board and rendering it on to the screen, and when you're reading input from the user to direct the next step in the game. But all of the actual logic - computing collision detection against the existing grid, computing the score, rotating blocks, etc. - is completely functional. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

CW Anderson

5:30 p.m.

To help learn some Haskell, I implemented a pole-balancing video game in Haskell, starting with the code for the S.A.R.A.H. road simulator by Maurício C. Antunes (thanks Maurício) that is included in the Gtk2Hs library demos. It demonstrates how to do the graphics, interact with the user via mouse buttons, and the use of IORef to maintain the state. You can download my implementation at http://www.cs.colostate.edu/~anderson/code/haskell/Pole.hs Chuck Anderson Andrew Coppin wrote:

...

If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

I'm particularly interested to know

1. How exactly would you do the graphical components? (Presumably there's some deep trickery with Gtk2hs that can draw free-form stuff like this.)

2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

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

-- View this message in context: http://www.nabble.com/Tetris-tf4839853.html#a13846985 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

Laurent Deniau

20 Nov 20 Nov

12:07 p.m.

Andrew Coppin wrote:

...

2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

Haskell taught me one thing (at least). The World is not mutating but it is moving. Physics shows that no movement (no time) means no World (in fact it means that you can't know if the World exists or not, which is the same). You can take the (discrete) analogy of a (time) *sequence* of pictures which builds a movie. The pictures are immutable and so is the movie, but looking quickly at the pictures makes the movie looking like a mutable picture. Everything here is about (time) sequence, not mutability. It is the same about Monad. Monad are not about side effects nor mutability, but about sequencing. It uses the principle of causality that one need to apply a function to its arguments before it returns a result (and encapsulates this behavior in an object). Note that it says nothing about lazy or eager evaluation, since the result can be either a value or an (lazy) expression which evaluates to the value. What this latter expression captures is the sequence of evaluation to perform to get the value. Again, everything here is about sequence, not mutability. Mutability is an (apparent) optimization. Creating a new state from the previous state in the (time) sequence has a cost (note the functional nature of this transition). Since a big part of this process can be shared to reduce this cost, namely creating the storage / structure / value / whatever of the state, one can think to reuse as much as possible. In the movie analogy, this optimization is called mpeg compression which only encodes the changes between images in the sequence. The Haskell compiler can also do this kind of optimization as soon as it doesn't change the observable behavior of the program. This means that a Haskell program can have/deal with mutable states resulting from an optimization. This mutability is explicit within the IO Monad since it is the standard way to communicate with the computer World. So the only (required) mutable states in the game are related to the IO, not to the game states as one might think. But the encapsulation of these states inside some monads may let the compiler do some optimization for you. my 2 cents of Euro. a+, ld.

Jeremy Shaw

1:49 p.m.

At Mon, 19 Nov 2007 21:25:23 +0000, Andrew Coppin wrote:

...

If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

A minimal openGL haskell tetris clone: http://haskell-tetris.pbwiki.com/Main j.

Don Stewart

2 p.m.

jeremy.shaw:

...

At Mon, 19 Nov 2007 21:25:23 +0000, Andrew Coppin wrote:

...
If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

A minimal openGL haskell tetris clone:

http://haskell-tetris.pbwiki.com/Main

Cool! Hadn't seen this.

Andrew Coppin

2:31 p.m.

Jeremy Shaw wrote:

...

http://haskell-tetris.pbwiki.com/Main

A minimal openGL haskell tetris clone:

Neat! I shall have to give this a try...

Andrew Coppin

21 Nov 21 Nov

1:26 p.m.

New subject: More problems [Tetris]

Andrew Coppin wrote:

...

Jeremy Shaw wrote:

...
http://haskell-tetris.pbwiki.com/Main A minimal openGL haskell tetris clone:

Neat! I shall have to give this a try...

Negatro. I can't get this to work. :-( It seems that the [Haskell] GLUT package isn't installed. That's really weird - I'm *sure* it used to be bundled with GHC, and I can't see anything in any release notes to say it has been removed. And the online Haddoc documentation states that it's there. But my local copy says it isn't, and ghc-pkg says it isn't. OpenGL is instilled, but not GLUT. Oh well, that's pretty weird, but it's OK, I'll just install GLUT from Hackage. ;-) But, alas, no. That doesn't work either. The reason? Well, apparently Cabal can't find "sh". This is probably related to the fact that "sh" doesn't exist on my computer. On further inspection, it seems that part of the installation routine is written as a bash script. Oh cool. At this point, I gave up. Not wanting to sound like somebody who just complains all day, but this kind of thing seems to be pretty typical of trying to get just about anything Haskell-related to work here. (I also elided the minor detail that I first had to work out how to extract files from a Tar/GZip file. It's common on Unix, but Windows doesn't know what to make of it. Fortunately, I happen to know the right 3rd party tools to fix this; I'm not sure if everyone else who might try to use Haskell stuff does.) In short, lots of Haskell-related things seem to be extremely Unix-centric and downright unfriendly towards anybody trying to set things up on Windows. If I didn't already know a bit about Unix, I'd be *really* stuck! Now, I have two questions for the cafe: 1. Did GHC ever include GLUT? Or is my memory really that defective? I'm *sure* it used to... but I don't see any note to say it was removed, so maybe it was only ever there on Unix? 2. Can anybody think of a way I can actually get this Tetris program to work?

Peter Verswyvelen

2:11 p.m.

New subject: More problems [Tetris]

No GLUT is not bundled with GHC 6.8.1 anymore. Yes, that is weird. It was bundled with GHC 6.6.1. But installing it for GHC 6.8.1 is really easy, but you have to install msys/mingw first. So if you want to do some experiments with OpenGL without having to install other stuff, use GHC 6.6.1. *** Don't give up, it's lots of fun once it works *** Yeah, Windows users are a bit second class citizens when it comes to Haskell, but that's the way it works. Personally I can understand that. Windows is really a mess. My first computer with a real OS was an Amiga, and I must say that I miss that elegance and simplicity in *all* modern OSes. For many people, Linux seems to have that elegance. Personally, I don't see it, but I don't see that in Windows either... -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Andrew Coppin Sent: Wednesday, November 21, 2007 7:27 PM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] More problems [Tetris] Andrew Coppin wrote:

...

Jeremy Shaw wrote:

...
http://haskell-tetris.pbwiki.com/Main A minimal openGL haskell tetris clone:

Neat! I shall have to give this a try...

Peter Verswyvelen

2:25 p.m.

New subject: More problems [Tetris]

Andrew, I tried the Tetris with GHC 6.6.1 on Windows, and it works out of the box. Of course you must make sure a suitable GLUT32.DLL is in your path. However, it's not really a nice tetris is it :) And it is very monadic. I wrote a Tetris clone once on the Amiga. But I won't do that again. And personally I prefer Bombliss. I multiplayer version over the network of Bombliss would be a really nice Haskell project :) -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Peter Verswyvelen Sent: Wednesday, November 21, 2007 8:11 PM To: 'Andrew Coppin'; haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] More problems [Tetris] No GLUT is not bundled with GHC 6.8.1 anymore. Yes, that is weird. It was bundled with GHC 6.6.1. But installing it for GHC 6.8.1 is really easy, but you have to install msys/mingw first. So if you want to do some experiments with OpenGL without having to install other stuff, use GHC 6.6.1. *** Don't give up, it's lots of fun once it works *** Yeah, Windows users are a bit second class citizens when it comes to Haskell, but that's the way it works. Personally I can understand that. Windows is really a mess. My first computer with a real OS was an Amiga, and I must say that I miss that elegance and simplicity in *all* modern OSes. For many people, Linux seems to have that elegance. Personally, I don't see it, but I don't see that in Windows either... -----Original Message----- From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Andrew Coppin Sent: Wednesday, November 21, 2007 7:27 PM To: haskell-cafe@haskell.org Subject: [Haskell-cafe] More problems [Tetris] Andrew Coppin wrote:

...

Jeremy Shaw wrote:

...
http://haskell-tetris.pbwiki.com/Main A minimal openGL haskell tetris clone:

Neat! I shall have to give this a try...

Andrew Coppin

3:31 p.m.

New subject: More problems [Tetris]

Peter Verswyvelen wrote:

...

No GLUT is not bundled with GHC 6.8.1 anymore. Yes, that is weird.

It was bundled with GHC 6.6.1.

OK, so it was there, but now it isn't, and this fact isn't documented. Should I file a ticket for this? (To get the release notes amended if nothing else.) Was GLUT removed on purpose, or was this an oversight? (Is it still there on Unix?)

...

But installing it for GHC 6.8.1 is really easy, but you have to install msys/mingw first.

Not keen on installing a Unix emulator just so I can install stuff from Hackage. (Surely this shouldn't be necessary?)

...

So if you want to do some experiments with OpenGL without having to install other stuff, use GHC 6.6.1.

I'm only trying to get this Tetris program to work. I'm more likely to want to play with Cairo or SDL. ;-)

...

*** Don't give up, it's lots of fun once it works ***

LOL! I'm sure. ;-)

...

Yeah, Windows users are a bit second class citizens when it comes to Haskell, but that's the way it works. Personally I can understand that.

Well, they say there aren't many Windows users which makes it harder to test. I can understand that... Heck, if I knew what buttons to press, I'd have a go at improving the situation. (We already fixed is so that the new streams thing on Hackage works out-of-the-box on Windows now... or at least will do with the next release of Cabal.)

...

Windows is really a mess. My first computer with a real OS was an Amiga, and I must say that I miss that elegance and simplicity in *all* modern OSes. For many people, Linux seems to have that elegance. Personally, I don't see it, but I don't see that in Windows either...

I too have an Amiga sitting next to my desk. Windows suffers from extreme featuritus. Worse even than Yahoo! does. Unix seems to suffer from being an ah-hoc thing encrusted with 28,000 layers of backwards compatibility. It's far too messy for my liking. Much more *reliable* than Windows, but seemingly no more elegant conceptually. I keep dreaming that one day I'll write a propper OS... but (surprise!) it hasn't happened yet. Anyway, this is drifting radically off-topic!

Bayley, Alistair

22 Nov 22 Nov

4:37 a.m.

New subject: More problems [Tetris]

...

From: haskell-cafe-bounces@haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Andrew Coppin

...
But installing it for GHC 6.8.1 is really easy, but you have to install msys/mingw first.

Not keen on installing a Unix emulator just so I can install stuff from Hackage. (Surely this shouldn't be necessary?)

Well, you only have to install msys once, and then life will be just that little bit easier. I have a point of making it part of the standard re-install process for my laptop (which seems to be repaved about twice a year now, for various reasons). There are a few Haskell libraries whose build process assumes a unix-like environment, so sometimes it's just easier to drink the Kool-aid... Alistair ***************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. *****************************************************************

Alex Young

21 Nov 21 Nov

4:09 p.m.

New subject: More problems [Tetris]

Peter Verswyvelen wrote:

...

No GLUT is not bundled with GHC 6.8.1 anymore. Yes, that is weird.

It was bundled with GHC 6.6.1. But installing it for GHC 6.8.1 is really easy, but you have to install msys/mingw first. This is handled in Ruby-land by having binary packages available for Windows, either cross-compiled or donated by someone with an appropriate compiler. Would that be a possible here? Just a thought.

-- Alex

Jules Bean

22 Nov 22 Nov

5:41 a.m.

New subject: More problems [Tetris]

Peter Verswyvelen wrote:

...

No GLUT is not bundled with GHC 6.8.1 anymore. Yes, that is weird.

I think it's weird too, so I bug reported it: http://hackage.haskell.org/trac/ghc/ticket/1917 Jules

Aaron Denney

21 Nov 21 Nov

7:11 p.m.

New subject: More problems [Tetris]

On 2007-11-21, Andrew Coppin wrote:

...

In short, lots of Haskell-related things seem to be extremely Unix-centric and downright unfriendly towards anybody trying to set things up on Windows. If I didn't already know a bit about Unix, I'd be *really* stuck!

I'd say, rather, that windows is unfriendly towards open and working common standards. -- Aaron Denney -><-

Lennart Augustsson

22 Nov 22 Nov

5:23 a.m.

New subject: More problems [Tetris]

IMHO, no one in the right mind uses Windows voluntarily. :) I'm forced to use it at work, and it's a pain. But since many are forced to use Windows it would be nice if ghc was as well supported on Windows and Unix. On Nov 22, 2007 12:11 AM, Aaron Denney wrote:

...

On 2007-11-21, Andrew Coppin wrote:

...
In short, lots of Haskell-related things seem to be extremely Unix-centric and downright unfriendly towards anybody trying to set things up on Windows. If I didn't already know a bit about Unix, I'd be *really* stuck!

I'd say, rather, that windows is unfriendly towards open and working common standards.

-- Aaron Denney -><-

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

Andrew Coppin

2:25 p.m.

New subject: More problems [Tetris]

Lennart Augustsson wrote:

...

IMHO, no one in the right mind uses Windows voluntarily. :) I'm forced to use it at work, and it's a pain. But since many are forced to use Windows it would be nice if ghc was as well supported on Windows and Unix.

What he said. ;-) I will say this: GHC itself (and the libraries that come with it) seem to work very well on Windows already. Download installer, double-click, press [Next] a few times, congratulations, you have a fully functional (get it?!) Haskell development box. Not much to improve there. (Well... GHC only adds itself to the current user's PATH, not system-wide. A switch for this would be nice...) It's just installing anything from Hackage which turns out to be really difficult. I understand Windows developers are a tad rare round here, so maybe that's understandable. I'd certainly be interested in hearing about anything practical that I can do to improve things on the Windows side...

Brandon S. Allbery KF8NH

2:39 p.m.

New subject: More problems [Tetris]

On Nov 22, 2007, at 14:25 , Andrew Coppin wrote:

...

It's just installing anything from Hackage which turns out to be really difficult. I understand Windows developers are a tad rare round here, so maybe that's understandable. I'd certainly be interested in hearing about anything practical that I can do to improve things on the Windows side...

I suspect this requires a wrapper around Cabal so a suitably equipped Windows developer can build a package and then wrap it up in an InstallerVise (or etc.) installer. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Andrew Coppin

2:43 p.m.

New subject: More problems [Tetris]

Brandon S. Allbery KF8NH wrote:

...

On Nov 22, 2007, at 14:25 , Andrew Coppin wrote:

...
It's just installing anything from Hackage which turns out to be really difficult. I understand Windows developers are a tad rare round here, so maybe that's understandable. I'd certainly be interested in hearing about anything practical that I can do to improve things on the Windows side...

I suspect this requires a wrapper around Cabal so a suitably equipped Windows developer can build a package and then wrap it up in an InstallerVise (or etc.) installer.

What's actually involved in installing a 100% Haskell package? I was under the impression you just need to put the compiled code somewhere nice, and then tell GHC where you put it? Would it not be possible to write a Cabal package description that just takes a bunch of binary objects, puts them somewhere, and tells GHC? (Obviously if the package is a binding to some external library things become more complex...)

Andrew Coppin

2:16 p.m.

New subject: More problems [Tetris]

Aaron Denney wrote:

...

On 2007-11-21, Andrew Coppin wrote:

...
In short, lots of Haskell-related things seem to be extremely Unix-centric and downright unfriendly towards anybody trying to set things up on Windows. If I didn't already know a bit about Unix, I'd be *really* stuck!

I'd say, rather, that windows is unfriendly towards open and working common standards.

Or you could say that Windows *is* a "common standard". (I stop short of "working".) But it's unclear where such circular semantic fidgetting gets us. ;-)

Jonathan Cast

2:52 p.m.

New subject: More problems [Tetris]

On 22 Nov 2007, at 11:16 AM, Andrew Coppin wrote:

...

Aaron Denney wrote:

...
On 2007-11-21, Andrew Coppin wrote:

...
In short, lots of Haskell-related things seem to be extremely Unix-centric and downright unfriendly towards anybody trying to set things up on Windows. If I didn't already know a bit about Unix, I'd be *really* stuck!

I'd say, rather, that windows is unfriendly towards open and working common standards.

Or you could say that Windows *is* a "common standard". (I stop short of "working".) But it's unclear where such circular semantic fidgetting gets us. ;-)

Or you could say that focusing on ‘standards’ is a good way to side- step the issue of whether those standards are technically sound or not; and that if the combination of Windows and Haskell is technically unsound, there are four possibilities: (0) Windows and Haskell are both themselves technically unsound; (1) Windows is technically unsound, and Windows + Haskell incorporates this unsoundness; (2) Haskell is technically unsound, and Windows + Haskell incorporates this unsoundness; or (3) Windows and Haskell are both technically sound, but in incompatible ways. I lean towards (1), naturally. But this doesn't answer the question of whether the lowest-cost solution is to fix Windows or work around it, of course. jcc

Bulat Ziganshin

4:45 a.m.

New subject: More problems [Tetris]

Hello Andrew, Wednesday, November 21, 2007, 9:26:45 PM, you wrote:

...

It seems that the [Haskell] GLUT package isn't installed.

at least i remember my own proposal to remove from GHC distribution graphics packages - because they are fat, rarely used and mostly outdated

...

Hackage. ;-) But, alas, no. That doesn't work either. The reason? Well, apparently Cabal can't find "sh".

cabal by itself doesn't need sh. it's either required by library installation or it as just information message

...

Not wanting to sound like somebody who just complains all day, but this kind of thing seems to be pretty typical of trying to get just about anything Haskell-related to work here.

i agree. haskell world today is something like unix world 10 years ago. it attracts qualified people which step-by-step makes this world more attractive for "casual users". but we are in the middle of the long road -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Andrew Coppin

2:22 p.m.

New subject: More problems [Tetris]

Bulat Ziganshin wrote:

...

Hello Andrew,

Wednesday, November 21, 2007, 9:26:45 PM, you wrote:

...
Hackage. ;-) But, alas, no. That doesn't work either. The reason? Well, apparently Cabal can't find "sh".

cabal by itself doesn't need sh. it's either required by library installation or it as just information message

Cabal doesn't give me this message for other packages, so presumably something about GLUT makes Cabal think that sh is necessary.

...

i agree. haskell world today is something like unix world 10 years ago. it attracts qualified people which step-by-step makes this world more attractive for "casual users". but we are in the middle of the long road

OK, so we agree a problem exists. Now, what can we do to solve it? :-) My first question would be: - Is there a viable alternative to sh scripts for installing packages? If there is, it would seem it's just an issue of getting everybody to migrate to it. If there isn't, it looks like we need to make one...

Brandon S. Allbery KF8NH

2:58 p.m.

New subject: More problems [Tetris]

On Nov 22, 2007, at 14:22 , Andrew Coppin wrote:

...

My first question would be:

- Is there a viable alternative to sh scripts for installing packages?

If there is, it would seem it's just an issue of getting everybody to migrate to it. If there isn't, it looks like we need to make one...

ActiveState Perl? Unfortunately, as long as you can't guarantee everything being installed in consistent places and/or invoked in consistent ways (which on Windows is well-nigh impossible due to conflicting version requirements) you need a way to search the system for stuff. If you don't want to require that people on Windows have a reasonable scripting language installed for such, you get to bundle (or write) one. It would be nice if Windows devs had come up with something like pkg- config; it'd be possible to do a minimal implementation just using CMD.EXE scripts (don't bother with the full GNU pkg-config framework, just have each package bundle a %foo%-CONFIG.CMD that dumps locations, compiler flags, etc. in an easily parsed form) and then a relatively simple Haskell module could check for packages by running their config scripts. But this requires convincing all the non- Haskell third party libraries (GLUT, SDL, etc.) to add config scripts to their distributions; practically, I don't see this happening. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Lennart Augustsson

20 Nov 20 Nov

7:11 p.m.

I implemented Tetris in LML long before Haskell existed. It was text based, but looked good with a custom font. :) Haskell has no problem with state, it's just explicit. -- Lennart On Nov 19, 2007 9:25 PM, Andrew Coppin wrote:

...

If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

I'm particularly interested to know

1. How exactly would you do the graphical components? (Presumably there's some deep trickery with Gtk2hs that can draw free-form stuff like this.)

2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

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

Conal Elliott

9:27 p.m.

Moreover, functional programming makes it easy to have much more state than imperative programming, namely state over *continuous* time. The temporally discrete time imposed by the imperative model is pretty puny in comparison. Continuous (or "resolution-independent") time has the same advantages as continuous space: resource-adaptive, scalable, transformable. On Nov 20, 2007 4:11 PM, Lennart Augustsson wrote:

...

I implemented Tetris in LML long before Haskell existed. It was text based, but looked good with a custom font. :)

Haskell has no problem with state, it's just explicit.

-- Lennart

On Nov 19, 2007 9:25 PM, Andrew Coppin wrote:

...
If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

I'm particularly interested to know

1. How exactly would you do the graphical components? (Presumably there's some deep trickery with Gtk2hs that can draw free-form stuff like this.)

2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

_______________________________________________ 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

Peter Verswyvelen

21 Nov 21 Nov

6:09 a.m.

First of all Conal, I find all of your work amazingly cool. Do you have fan list? ;-) Conal Elliott wrote:

...

Moreover, functional programming makes it easy to have much more state than imperative programming, namely state over *continuous* time. The temporally discrete time imposed by the imperative model is pretty puny in comparison. Continuous (or "resolution-independent") time has the same advantages as continuous space: resource-adaptive, scalable, transformable. Yes, that's true, but isn't that also the problem with FRP? I mean, most of the papers I'm reading about (A)FRP indicate that no matter how nice it is to have the continuous time model, to get fine grained control over execution times and resources, one needs to fall back to the discrete delta-time approach? And you still need to think about where you have to introduce delays to avoid infinite loops? I might be wrong, since I don't understand everything in these papers yet ;-)

About continuous time; it is in fact, not really continuous is it, since floats are used to approximate time. So the longer your program runs, the less accurate an absolute time value will become no? Okay, if you use 64-bit floats, you will have to let is run a very long time :-) Since nobody replied yet on my question about the future of (A)FRP, maybe I can ask it again here? What is the future for FRP? Are other approaches better suitable for reactive applications? About Monadius, yes, I also think it's very nice. It is based on IMO one of the greatest videogames ever, Gradius (aka Nemesis). You don't want to know how much money I put in those Konami arcade machines ;-) But Monadius just mimics the imperative discrete time approach, which of course, does work, since 99.99% or so of the videogames on the market use this approach. Monadius is really easy to understand for Haskell newbies, and it shows that you actually can make a nice game without using incredibly tricky abstractions :-) However, I found that as soon as I try to make my own combinators, to piece several "reactive objects" together, I always seem to mimic FRP, and finally AFRP. Cheers, Peter Conal Elliott wrote:

...

Moreover, functional programming makes it easy to have much more state than imperative programming, namely state over *continuous* time. The temporally discrete time imposed by the imperative model is pretty puny in comparison. Continuous (or "resolution-independent") time has the same advantages as continuous space: resource-adaptive, scalable, transformable.

On Nov 20, 2007 4:11 PM, Lennart Augustsson mailto:lennart@augustsson.net> wrote:

I implemented Tetris in LML long before Haskell existed. It was text based, but looked good with a custom font. :)

Haskell has no problem with state, it's just explicit.

-- Lennart

On Nov 19, 2007 9:25 PM, Andrew Coppin mailto:andrewcoppin@btinternet.com> wrote:

If you were going to implement Tetris in Haskell, how would you do it?

(For that matter, has anybody already *done* it? It would probably make a nice example program...)

I'm particularly interested to know

1. How exactly would you do the graphical components? (Presumably there's some deep trickery with Gtk2hs that can draw free-form stuff like this.)

2. How do you implement a program that is fundamentally about state mutation in a programming language which abhors state mutation?

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

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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

Laurent Deniau

6:49 a.m.

Peter Verswyvelen wrote:

...

Conal Elliott wrote:

...
Moreover, functional programming makes it easy to have much more state than imperative programming, namely state over *continuous* time. The temporally discrete time imposed by the imperative model is pretty puny in comparison. Continuous (or "resolution-independent") time has the same advantages as continuous space: resource-adaptive, scalable, transformable. Yes, that's true, but isn't that also the problem with FRP? I mean, most of the papers I'm reading about (A)FRP indicate that no matter how nice it is to have the continuous time model

I agree with Conal, it's not a continuous time model but a resolution-independent time model. The reason it that Arrows (like Monads) encapsulate the sequence of transitions. Unless the time is a parameter of the transition, it is independent of the time (resolution), but still captures its ordered nature.

...

to get fine grained control over execution times and resources, one needs to fall back to the discrete delta-time approach?

If you need synchronization, yes.

...

And you still need to think about where you have to introduce delays to avoid infinite loops?

I don't see why, unless you want to have a memory or explicitly stop the time which means it's a parameter of the transition as mention above (but instantaneous transitions seems strange). So, the causality of the transitions with a discrete time should not lead to infinite loops. The time delay exists de facto.

...

Since nobody replied yet on my question about the future of (A)FRP, maybe I can ask it again here? What is the future for FRP? Are other approaches better suitable for reactive applications?

I missed your question, but it's an interesting question. I found very interesting and instructive the paper of Hai Liu and Paul Hudak on the problem of space leaks in FRP. a+, ld.

Peter Verswyvelen

7:56 a.m.

Laurent Deniau wrote:

...

...
And you still need to think about where you have to introduce delays to avoid infinite loops? I don't see why, unless you want to have a memory or explicitly stop

Peter Verswyvelen wrote: the time which means it's a parameter of the transition as mention above (but instantaneous transitions seems strange). So, the causality of the transitions with a discrete time should not lead to infinite loops. The time delay exists de facto. I'm currently reading "FRP, Continued". Maybe I got confused by the text on page 56, which introduces a delay (noEvent --> addOrDelCTs) to avoid an infinite loop.

...

...
Since nobody replied yet on my question about the future of (A)FRP, maybe I can ask it again here? What is the future for FRP? Are other approaches better suitable for reactive applications?

I missed your question, but it's an interesting question. I found very interesting and instructive the paper of Hai Liu and Paul Hudak on the problem of space leaks in FRP.

Yes that is a very interesting paper, but since I'm still trying to understand and use Yampa, I will have to re-read the paper. It would be nice if Paul Hudak wrote a "Haskell HIGH School of Expression" book, explaining Yampa, because I really enjoyed the SOE book.

Laurent Deniau

23 Nov 23 Nov

5:23 a.m.

Peter Verswyvelen wrote:

...

Laurent Deniau wrote:

...
...
And you still need to think about where you have to introduce delays to avoid infinite loops? I don't see why, unless you want to have a memory or explicitly stop

Peter Verswyvelen wrote: the time which means it's a parameter of the transition as mention above (but instantaneous transitions seems strange). So, the causality of the transitions with a discrete time should not lead to infinite loops. The time delay exists de facto. I'm currently reading "FRP, Continued". Maybe I got confused by the text on page 56, which introduces a delay (noEvent --> addOrDelCTs) to avoid an infinite loop.

I haven't read (yet) the paper (so take my remark with care), but looking roughly at this function, it seems that it tries to avoid infinite loop by introducing a delay (noEvent). This is like tail in a stream-based Fibonacci. You need to delay (or shift for a stream) input1 vs input2 because input2 is the output of the the current step/transition, otherwise you get an infinite loop. This is because of the recursive nature of what the transition needs to do (the generator), not with the time. An analogy of FRP in the OO world is the Event-based loop. If an event queues another event which itself (re)queue the current event, you'll get an infinite loop (or more probable a deadlock ;-) as well (in CPS-based FRP, the chain of continuations becomes infinite). I would say that conceptually (may be wrong in this particular case), this happens because you do not respect the principle of causality, that is you're looking at the future. This is a common pattern in adaptive theory where memory is delays. In that case you never look at the future, you can only estimate it (in the case of predictive model). Nevertheless, I think that AFRP and Signal match very well adaptive theory (signal processing or control theory). If I were good enough in Haskell (and had the time to do it, sic!), I would give a try to build adaptive systems on top of Yampa. The problem is that for efficiency reason one needs to mix Signals with things like Fast Arrays where arrays on the lhs are mutables but becomes immutable once on the rhs. I dream of a lib doing efficient signal processing on top of these two ideas.

...

...
...
Since nobody replied yet on my question about the future of (A)FRP, maybe I can ask it again here? What is the future for FRP? Are other approaches better suitable for reactive applications?

I missed your question, but it's an interesting question. I found very interesting and instructive the paper of Hai Liu and Paul Hudak on the problem of space leaks in FRP.

Yes that is a very interesting paper, but since I'm still trying to understand and use Yampa, I will have to re-read the paper. It would be nice if Paul Hudak wrote a "Haskell HIGH School of Expression" book, explaining Yampa, because I really enjoyed the SOE book.

I agree! a+, ld.

Conal Elliott

21 Nov 21 Nov

8:54 p.m.

On Nov 21, 2007 3:49 AM, Laurent Deniau wrote:

...

Peter Verswyvelen wrote:

...
Conal Elliott wrote:

...
Moreover, functional programming makes it easy to have much more state than imperative programming, namely state over *continuous* time. The temporally discrete time imposed by the imperative model is pretty puny in comparison. Continuous (or "resolution-independent") time has the same advantages as continuous space: resource-adaptive, scalable, transformable. Yes, that's true, but isn't that also the problem with FRP? I mean, most of the papers I'm reading about (A)FRP indicate that no matter how nice it is to have the continuous time model

...

I agree with Conal, it's not a continuous time model but a resolution-independent time model.

What do mean by resolution-independent vs continuous? I meant them more-or-less synonymously. Semantically, there's no notion of resolution. When it's time to introduce a resolution for discrete rendering, there's no resolution imposed by the model.

...

The reason it that Arrows (like Monads) encapsulate the sequence of transitions. Unless the time is a parameter of the transition, it is independent of the time (resolution), but still captures its ordered nature.

I'm confused again. I don't think of Arrow as implying transitions at all.

...

...
to get fine grained control over execution times and resources, one needs to fall back to the discrete delta-time approach?

...

If you need synchronization, yes.

Why? What about synchronization implies discretness in the model? - Conal

Laurent Deniau

23 Nov 23 Nov

3:09 a.m.

Conal Elliott wrote:

...

On Nov 21, 2007 3:49 AM, Laurent Deniau mailto:laurent.deniau@cern.ch> wrote:

...
Peter Verswyvelen wrote:

...
Conal Elliott wrote:

...
Moreover, functional programming makes it easy to have much more state than imperative programming, namely state over *continuous* time. The temporally discrete time imposed by the imperative model is pretty puny in comparison. Continuous (or "resolution-independent") time has the same advantages as continuous space: resource-adaptive, scalable, transformable. Yes, that's true, but isn't that also the problem with FRP? I mean, most of the papers I'm reading about (A)FRP indicate that no matter how nice it is to have the continuous time model

...
I agree with Conal, it's not a continuous time model but a resolution-independent time model.

What do mean by resolution-independent vs continuous?

I mean time may or may not be part or the model in FRP.

...

I meant them more-or-less synonymously. Semantically, there's no notion of resolution. When it's time to introduce a resolution for discrete rendering, there's no resolution imposed by the model.

Right. This is why I do not see the relation with the number of bits in a float. Time could be represented by states, in the sens of a state machine with asynchronous events.

...

...
The reason it that Arrows (like Monads) encapsulate the sequence of transitions. Unless the time is a parameter of the transition, it is independent of the time (resolution), but still captures its ordered nature.

I'm confused again. I don't think of Arrow as implying transitions at all.

I call a transition the operator >>= for Monad, and arr for Arrow. I was maybe not clear in this point. The correct wording might be a computation.

...

...
...
to get fine grained control over execution times and resources, one needs to fall back to the discrete delta-time approach?

...
If you need synchronization, yes.

Why? What about synchronization implies discretness in the model?

Because it requires either specific states which are aware of each other (asynchronous events), or a known delta-time. How do you synchronize continuous events (I would says more continuous processes) ? Regards, ld.

Henrik Nilsson

21 Nov 21 Nov

6:57 a.m.

Hi Peter,

...

About continuous time; it is in fact, not really continuous is it, since floats are used to approximate time. So the longer your program runs, the less accurate an absolute time value will become no?

Well, yes and no. Yampa, at least, does not use absolute time internally, only time deltas, so the problem you describe only occurs if the programmer *explicitly* choose to accumulate absolute time, or *explicitly* make use of very large relative time intervals (e.g. combinators like "after" that emits an event after a given, relative, time interval). So, as always with floating point, or with any finite representation of numbers, the programmer has to understand the limitations and implications of the chosen representation. But this is not any inherent flaw of FRP or its Yampa incarnation as such. One could also imagine using some infinite-precision number representation with FRP instead of floating point. The fact that Yampa uses floating point is merely a pragmatic implementation choice. I believe I also saw someone asking about Modelica in this context. Modelica is a hybrid modelling and simulation language. Efficient simulation and accurate results are of key importance, and for that reason Modelica implementations use sophisticated numerical and symbolic methods. Unfortunately, this also limits the expressiveness of the language. In particular, Modelica cannot handle systems with highly dynamic structure like video games. Thus I don't think we'll see video games written purely in languages like Modelica any time soon, even if there is active research on making such languages cope better with structurally dynamic systems. (One could probably imagine using Modelica for handling game physics, though, i.e. as a component of a games programming suite.) Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

Conal Elliott

8:48 p.m.

Hi Peter,

...

First of all Conal, I find all of your work amazingly cool. Do you

have fan list? ;-) :)

...

Conal Elliott wrote:

...
Moreover, functional programming makes it easy to have much more

state than imperative programming, namely state over *continuous* time. The temporally discrete time imposed by the imperative model is pretty puny in comparison. Continuous (or "resolution-independent") time has the same advantages as continuous space: resource-adaptive, scalable, transformable.

...

Yes, that's true, but isn't that also the problem with FRP? I mean,

most of the papers I'm reading about (A)FRP indicate that no matter how nice it is to have the continuous time model, to get fine grained control over execution times and resources, one needs to fall back to the discrete delta-time approach? I haven't found that to be the case. I'd like to understand what specific implementation issues seem to conflict with continuous time. Can anyone help me out?

...

And you still need to think about where you have to introduce delays to avoid infinite loops? I might be wrong, since I don't understand everything in these papers yet ;-)

There were two places in Fran where timing was a bit delicate to get termination. I made sure that reactive behaviors don't change at the moment of the event occurrence, but rather immediately after it. You could call it an "infinitessimal delay". There was no delta>0. The other is very similar: ordinary differential equations (expressed recursively, using integration). Again, there was no time delta in the semantics. I also got the impression that some of the folks at Yale thought it necessary to add in some kind of (non-infinitessimal) delay, related to termination, but I don't know why. Maybe Henrik will comment.

...

About continuous time; it is in fact, not really continuous is it,

since floats are used to approximate time. So the longer your program runs, the less accurate an absolute time value will become no? Okay, if you use 64-bit floats, you will have to let is run a very long time :-) Sure. And yes 64 bits help. And we could certainly use a bigfloat representation to get really continuous time (and space).

...

Since nobody replied yet on my question about the future of (A)FRP,

maybe I can ask it again here? What is the future for FRP? Are other approaches better suitable for reactive applications? I've been itching to get back into (A)FRP to address some of these issues of continuous time, as well as modular interaction. Also toward making a much more efficient implementation, based mainly on data-driven evaluation. I've made some preliminary experiments, described at http://haskell.org/haskellwiki/DataDriven , used in Phooey, GuiTV, and Eros. Cheers, - Conal

Jon Harrop

9:29 a.m.

On Wednesday 21 November 2007 02:27, Conal Elliott wrote:

...

Moreover, functional programming makes it easy to have much more state than imperative programming, namely state over *continuous* time. The temporally discrete time imposed by the imperative model is pretty puny in comparison. Continuous (or "resolution-independent") time has the same advantages as continuous space: resource-adaptive, scalable, transformable.

This is a very odd statement: Imperative programming does nothing to impose discrete methods. In fact, the vast majority of continuous methods are described in the literature using an imperative style and implemented in software using an imperative style. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e

6391

Age (days ago)

6395

Last active (days ago)

List overview

Download

61 comments

23 participants

participants (23)

Aaron Denney
Alex Young
Andrew Coppin
Bayley, Alistair
Bit Connor
Brandon S. Allbery KF8NH
Bulat Ziganshin
Conal Elliott
CW Anderson
Don Stewart
Henrik Nilsson
Jeremy Shaw
Jon Harrop
Jonathan Cast
Jorge Marques Pelizzoni
Jules Bean
Laurent Deniau
Lennart Augustsson
Mathieu Boespflug
Peter Verswyvelen
Radosław Grzanka
Sebastian Sylvan
Stefan O'Rear

Tetris

Andrew Coppin

Jon Harrop

Mathieu Boespflug

Andrew Coppin

Radosław Grzanka

Andrew Coppin

Bit Connor

Radosław Grzanka

Andrew Coppin

Jorge Marques Pelizzoni

Andrew Coppin

Bit Connor

Andrew Coppin

Bit Connor

Jon Harrop

Radosław Grzanka

Andrew Coppin

Bit Connor

CW Anderson

Laurent Deniau

Jeremy Shaw

Andrew Coppin

Andrew Coppin

Andrew Coppin

Bayley, Alistair

Alex Young

Andrew Coppin

Andrew Coppin

Andrew Coppin

Jonathan Cast

Bulat Ziganshin

Andrew Coppin

Laurent Deniau

Laurent Deniau

Laurent Deniau

Henrik Nilsson

Jon Harrop

tags

participants (23)