Functional GLUT?

Question

I'm learning a bit of functional programming in Gambit-C Scheme by restricting myself to not using set!. I thought it might be fun to write a little OpenGL game using this environment, which seems to lend itself well to game development.

However, it seems to be difficult to stick to a functional style and avoid global state when using OpenGL and GLUT. I don't think this is a fundamental limitation of game programming, per se, but a callback-based API such as GLUT does not seem to work well with functional programming.

For example, I'm trying to think of the world as a stream of mutating state vectors which is a function of an interleaved list of timestep and user input events. This idea seems to be okay, but it doesn't seem to go easily with asynchronous programming. For instance, I have to register a callback for GLUT's display function, which should somehow be able to access the "current" item in this stream. Meanwhile, there's nothing to drive the stream forward by taking from it.

Ideally, I'd need something that is sort of "outside" GLUT, a main function which somehow depends (perhaps monadically) on the various GLUT functions having been executed at some point. How could such a style of game engine be developed around GLUT, or another way to ask is how could I most successfully isolate GLUT from my engine? Is it possible to have GLUT generate such an interleaved list of events to an outside procedure? How does Haskell handle this, for instance?

Answer 1

You're going to have a very hard time implementing a functional graphics system. Even the Haskell bindings to GLUT use imperative programming, through the IO monad. The closest thing I've heard to what you're trying to do is Functional Reactive Programming, but the libraries aren't ready for prime-time yet and there's a severe lack of real-world tutorials for it.

Answer 2

It's pretty fundemental to a state machine like openGL that it has state!

I don't see how you can have side-effect free functional programming when the side effect is drawing a collection of stuff to the screen.

Answer 3

You could look at the FieldTrip library for some ideas on functional graphics.

Answer 4

Having written this question made me think about it a little, and I'm starting to wonder if the answer lies in exploiting co-routines. If the game is a functional co-routine which is triggered by GLUT idle and display calls, this would very nicely separate the game logic from GLUT's architecture. For example, it's very likely that set! cannot be avoided, but if the GLUT callbacks used set! only to modify the stream which is being fed into a co-routine, this might create a very nice boundary. Any thoughts on this? I'll have to get more experience with co-routines before knowing more..