- First of all, all tutorials are using GLUT. Is that really the way to go with HOpenGL?

Probably not, but this is pretty typical of OpenGL tutorials – they use GLUT because it's simple to get going, and avoids having to demonstrate lots of things that are irrelevant to OpenGL.

They define (among other things) a onIdle and a onDraw function. That seems to me (at least for a game) not the way to go. onIdle updates the game logic, and onDraw draws the screen. As far as I can see, it does not make sense to update the game logic more than once between consecutive calls to onDraw. Same thing is true for class to onDraw between consecutive class to onIdle. Is this accounted for in the approach?

Actually, at least the onIdle running many times between onDraw is completely reasonable for a game... To keep your physics simulation accurate, you want nice, short, time steps, you don't necessarily want to be rendering each and every one of them though.

- In addition there is the onInput function. The onInput, onIdle and onDraw functions communicate (in the tutorials) using variables declared with newIORef. I come from the OO language C++ and almost no experience with functional languages. But this puzzles me. Basically they define global variables for the exchange between the callback functions, correct?!? So, for every piece of information I want to pass between these functions, I have to declare a newIORef variable?

Yeh, that's horribly horribly ugly. I would personally be spawning two threads, one to repeatedly update the game's state, and one to render. The functions for each thread would accept a channel as input. The game state updater would push game states into the channel, the renderer would pull all of them out and render the last one it finds.

In C/C++ I find GLUT not a very good approach and prefer plain OpenGL. Does it make sense to go with plain OpenGL in Haskell too? Are there any resources on how to do that?

I don't get how you use "plain OpenGL". There are no calls in OpenGL to set up graphics contexts, or accept user input etc. Personally, I would be using your own system's functions for doing this though – i.e. on Mac OS I would be using Cocoa to do it; on Linux GTK/Qt; on Windows .Net; etc. Bob