[clean-list] support for OpenGl

[Maks Verver]

Hi Jeremy.

At 12:39 4-7-2002 -0700, you wrote:
>I have not seen any Clean+OpenGL support, but I would love it have
>it. I can spend 5-15 hours per week helping on such a project. How
>many other people on this list are (1) interested in OpenGL for Clean
>(2) willing to commit any time to such a project, or (3) experienced
>enough to lead such a project.

Any useful library/API that can be ported to Clean would be nice to have, 
ofcourse, but I don't think OpenGL should be very high on the list of 
priorities. For example, I'd rather like to see some fundamental changes in 
the language itself and the standard library. Many issues have already been 
mentioned on this mailing list, as for example providing proper support for 
wide character sets, making the Clean library more portable by using a 
portable widget set, etcetera. Also, it would be nice to (finally) have the 
Clean 2.0 environment available for non-Windows operating systems.

So, if you ask me personally, I'd rather see the active Clean developers 
spend their time on more basic or commonly needed functionality, than on 
devising an OpenGL API , which is only required for very specific 
applications. Ofcourse, if there are people who are willing to spend their 
time on it, who am I to tell them not to?

The challenge in making the OpenGL API available for Clean, is to convert 
the script-based approach to a more functional one. For example, in OpenGL 
it is quite common to first define some set of data and later refer back to 
it. This works very well for a language like C, but the naive mapping to a 
functional language would result in passing around the state of the OpenGL 
environment. Although this works, it doesn't really fit the functional 
design paradigm and eliminates some of the (potential) benefits of using a 
functional language, like lazy evaluation and automated concurrency control.

It would be much better to first come up with a proper functional design of 
the OpenGL system, which focuses on operations and their results, instead 
of the order in which they are performend. For example, if one rendering 
pass fills a stencil buffer and a second one creates a 2D overlay (which 
doesn't have anything to do with the stencil buffer at all) the application 
programmer shouldn't have to be concerned about the order in which they 
happen, as he is in an imperative language (and in a naive conversion of 
the OpenGL API). This is one of the major benefits of using a functional 
language: defining just which operations are to be performed and how they 
are to be combined without defining how to obtain the results.

Another problem I can think of, is that enforcing the functional paradigm 
in an intrinsically non-functional environment like OpenGL, would result in 
a very inefficient system (especially when compared with raw C code). An 
extreme example would be to specifiy that a buffer is a list, so the first 
pixels from the list can be used before the rest is available, which can't 
really be done with OpenGL. In most OpenGL applications (think of CAD 
applications, for example) efficiency is of critical importance, which 
would mean that the balance between efficiency and a 'nice' functional 
approach would most likely be tipped in favor of efficiency.

If I, as an application developer, have the choice between using an 
efficient and neat API in an imperative language like C++, or using a 
functional API which may not be much less efficient, but doesn't really fit 
in with the functional approach of the rest of my application, I would 
certainly choose the first option. Consistency and a good design is often 
more important than the actual programming paradigm used, especially since 
most functional programmers are also familiar with at least one other 
programming paradigm.

I am completely unexperienced when it comes to designing any but the most 
trivial functional systems, so maybe a more skilled team of developers 
would be able to overcome the problems I sketched. My advise would be to 
first examine the OpenGL system closely and think of how it would be best 
implemented at a high level, before working out the details let alone 
writing any real code at all. If you have a good analysis and a sound 
design, you have a good (at least, much better) chance of finding a few 
capable and enthusiastic people on this mailing list who would like to help 
you with filling in the details and implementing your design.

Kind regards,
Maks Verver.