Well, for once, it's not particulary fast, but that's not a concern for all games(it's not slow either, but it's quite hard to optimize). The real deal is that it's a completely functional language with not much support, as far as games go. You won't find any graphics libraries, so you'll have to make them from scratch. Unless you have been programing in funcitonal languages for a long time, this will take an absurd ammount of time, and you probably won't be able to do it at all.
Haskell is great for math-oriented programs, but I wouldn't recommended for much else, in my opinion.
http://hackage.haskell.org/ is suppossed to be a good source for libraries, if you are intersted, but I can't get it to load.
As a professional Haskell programmer, I wouldn't say Haskell is harder to optimize than C++, I'd say it is different to optimize. Good Haskell programmers start with thinking about high-level concepts and algorithms right, rather than starting with (relatively) low-level, performance-focused good. And when they optimize, the things they're optimizing for are different: space leaks, excessive (and too little) laziness, appropriate data structure sharing (which can be tricky when using laziness to recursively compute a data structure) and so on.
After that, if necessary, they can look at lower-level details (escaping to a high-performance library in another language, skipping things like array bounds check, other low-level tricks, etc.). However, one of the powerful advantages of Haskell is that this sort of low-level, error-prone, ugly code can be isolated behind clean, predictable, functional interfaces. A great example of this is Haskell's ByteString library, where the low-level details are complex enough that I don't necessarily understand all of them, but the external interface is one even a beginning Haskell programmer can effectively and efficiently use.
I've used Haskell's OpenGL libraries some, and definitely recommend them over C++. OpenGL's callbacks feel much more natural in a functional language and the monadic do notation works very well at managing nested matrix transformations. Also, having an interpretive shell to play around with the types of functions is very useful.
And if use functional languages you can write all that math yourself - if you use C++ you can use all the C libs that have been debugged and tested for 30years.
Fraq was made in 2005 and it looks worse than quake 3, wich was made 6 years early (addmitedly by a big studio instead of jut one person, but the point still stands). It is possible to make games in Haskell, but it's closer to a theorical exercise than it is to an aproach to proffesional game-making.
addmitedly by a big studio instead of jut one person, but the point still stands
The point doesn't really stand, no. A big studio making a game over a long time period will obviously do a much better job than an undergraduate writing his thesis (yes, Frag was an undergrad thesis project).
To be fair, I think there are legitimate difficulties making games in Haskell, primarily related to the predictability of performance. GHC is a complicated and rather ingenious compiler incorporating many optimizations. While this is useful, it also means that performance (especially the responsiveness of the GC) can be unpredictable. Predictability of performance is quite important for games. In fact, this could be a good reason to try writing games in Ocaml.
The more probable reason is simply that the set of people working on big-budget games with the expertise to do in Haskell what they've learned to do in C++ is small.
haskell, libSDL, and OS X are a match made in hell. I recently tried this, and all sorts of dylib problems on my system lead me to believe its just not practical.
Are there other 3D/multimedia frameworks that play better w/Haskell? Or is it just raw OpenGL?
