It takes a lot of effort to develop a good library.
First of all, from now on, I want to point out that I am not so good at english, so I'll be often unclear. I am really sorry for this. And, I've not been unclear, just excessive in what I said. I am not criticizing anything, I've used GLUI in the past and found it fast and bugfree, for example. What I had in mind, and didn't say, is that it *might be* that reimplementing GLUI in haskell, following its design principles, could take less time than one could imagine, and bring a type-safe implementation. This is not true for QT, for example, which is full of so many functionalities no one can think of re-implementing it. Anyway I am not willing to reimplement GLUI, so it was not a critique, just my opinion (and I am just a computer science student, undergraduated, so my opinion doesn't matter so much :). Of course, It absolutely wasn't a critique of FFI in Haskell. It's not only useful but also necessary, for example for OpenGL or OpenAL, without counting that, even if GTK is NOT bugfree, there are many people that want or *need* to program for gtk, and could be interested in haskell. And, it's a programmer's choice what to consider part of the bare machine (and write an FFI binding) and what to consider "the software" and prefer to write it in haskell. What I am looking forward is to take an "haskell like" UI design and implement it, but parametrized in respect to the actions to be taken. So it could be reasonable to implement my design by myself, a binding for GLUI, and to instantiate my more abstract design using calls to GLUI (whose binding would surely result in a very "imperative" feeling). And, on the other side, to implement some "cool" widget in haskell+opengl, using the visual enhancements that opengl can give, and to instantiate the abstract UI with this widget set. In fact I am using console stubs by now, because I'm focusing on what structure is better for a file manager. An haskell program written for the abstract UI could then use one or another. It's just an experiment, I want to keep things well separated.
when the machine is thrashing, when handling exceptions, when the thread allocation limit is reached, etc. (I single Haskell out here because by making more things implicit than many other languages, Haskell makes it harder to reason about and deal with failure.)
It's a problem, but it's what we have to study. We cannot think that nothing serious can be done in Haskell because memory exhaustion would crash the program. Yes, I still have to read the articles around about imprecise exceptions ...
For this reason, I think it makes a lot more sense to incorporate existing libraries into Haskell and then build cleaner layers on top.
Yes, in fact, I am going to split my UI to allow this, but I want to play with opengl and have a funny toy-like visually-astonishing opengl widget set. Nothing more than that. And, besides, I know I won't succeed, but I have to try. If someone else will make a binding for GLUI I will ensure that my "clean" design (I am almost sure I will copy fudgets or ih, just let me some time to study both) will be implementable with GLUI. I need to clarify that I spoke too fast, and made a mistake. What I want to do in my spare time is a binding to a font library because *I* consider it more important. But this doesn't mean this isn't important, I agree. Vincenzo Ciancia