...

I need to write functions fast and efective. Math, heuristic, metadata and expert systems are better in haskell. If I could use haskel from C, I would do it. The problem are optimalizations, which are a critical change in algorithm. Other (and me too) won't understand my concepts. The speed and usability of Haskell is a good argument to use and learn it.

I can buy that. Well, one can actually call into Haskell from C. It is less commonly done, but very possible. Skim through the FFI addendum; you can export static functions (foreign export) or arbitrary thunks (with the confusingly named foreign import "wrapper"). If you are real adventurous, you can tie directly into the GHC API from the C side as well (although I'm not sure I can seriously recommend this method).

Having said that, if you feel that Haskell has sufficient advantages to warrant its use, I don't think you lose much by writing your main loops etc. in Haskell as well, and I would recommend you go with the labeled record technique to contain your program state.

I too am working on a Haskell 3d renderer. However, my motivation is mostly inspired by Conal Elliott's Tbag and Vertigo projects. In my opinion, geometry, expressions and most 3d technologies fit naturally with the functional approach, like you said ("math, heuristic, metadata and expert systems"). Haskell's lazy execution is where I see opportunity for parallel optimization. Think about all the computed pixels and polygons that we throw away in our culling and clipping. Now if we can structure the system inside out .... (do you see what I am getting at?) Having written several keyframe system, I feel that Fran's frameless timing approach is ingenious (Hudak's School of Expression book has an excellent section describing its motivation). Though I am not without reservation in all of this, paying close attention to the graphics world, where things are progressively moving towards programmable hardware. IMO, Vertigo is a good example of a practical application using Haskell. I think that the division between where does functional stops and where imperative starts will be a key deciding factor in the performance feasability as well as adaptability for haskell software in the real graphics world. In other words, 1 million IORefs make me feel quite unsettled. Anyone care to comment on the feasability of those hypothesis? jake