[HOpenGL] GL utilities, toolkits, and questions..

[Nick Name]

> 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