Re: [Haskell-cafe] Tetris
Conal Elliott wrote: On Nov 21, 2007 3:49 AM, Laurent Deniau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
Peter Verswyvelen wrote: Laurent Deniau wrote: Peter Verswyvelen 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 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
On Nov 21, 2007 5:00 PM, Peter Verswyvelen [EMAIL PROTECTED] 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 [EMAIL PROTECTED] 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
Laurent Deniau wrote: Peter Verswyvelen 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 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
2007/11/21, Conal Elliott [EMAIL PROTECTED]: 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
On Nov 21, 2007 3:49 AM, Laurent Deniau [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
At Mon, 19 Nov 2007 21:25:23 +, 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
jeremy.shaw: At Mon, 19 Nov 2007 21:25:23 +, 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
Jeremy Shaw wrote: http://haskell-tetris.pbwiki.com/Main A minimal openGL haskell tetris clone: Neat! I shall have to give this a try... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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-UI-GLUT.html Cheers, Radek. -- Codeside: http://codeside.org/ Przedszkole Miejskie nr 86 w Lodzi: http://www.pm86.pl/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
On Tue, Nov 20, 2007 at 07:27:48PM +, 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 signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
Stefan O'Rear wrote: On Tue, Nov 20, 2007 at 07:27:48PM +, 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.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
2007/11/20, Bit Connor [EMAIL PROTECTED]: 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/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 [EMAIL PROTECTED] 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
Re: [Haskell-cafe] Tetris
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
On Nov 19, 2007 9:25 PM, Andrew Coppin [EMAIL PROTECTED] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tetris
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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
