Uhm... and what if I write some runtines in plain C, then bind them to Haskell and and use then as in OOP:
[snip]
Is this apoarch safe enougth, what do you think?
If you do it carefully. But why? It sounds like you are planning to write a transliteration of the code you would write in C, without leveraging the advantages of Haskell. Which brings us to the critical question; what properties of Haskell cause you to want to develop your program using it? The answer to that question should direct your design choices.
A 3D engine aproach is a bit problematic (I can't describe it correctly in English... I'm a slovak...). Behind polygons, textures, HUD GUI and efects are mathematic functions, methods to solve problems, physics, data representations, heuristic algoritms, "unkown time living meta data", skripting language and sometimes expert systems, like simplified neuron networks. Behind these is memory handling, loops, heavy algorithm optimaliations and bugs.
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.