[Haskell-cafe] lazy Graphics, was - How to variables

[Jake Luck]

>> 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