Dylan Thurston cites :
... if we [...] want an adapted functional language, either we will have to wait quite long, or perhaps it is the time to invent another language, with a more dynamic type system, with intrinsic graphic utilities, and other goodies.
For myself, I don't see a problem here. For "intrinsic graphic utilities", someone has to write the graphic libraries. (You don't mean they should be built into the language, do you?) The type system is about as strong as anyone knows how to make a static type system; and it's not too hard to fall back on run-time type checking when necessary (as Sergey does in BAL).
Look what happens with functional graphics. Dozens of really good papers, I could mention many names here. (Some bad papers as well, some people formalize and formalize without any contact with reality...) So, one may want to check all this. You take Alastair Reid's Hugs graphic library, and you discover that: The IO monadic framework is so rigid that you program imperatively, and after a few minutes you ask yourself why for goodness sake do it in Haskell? The programming style is not functional at all. In C++ or Java you do it faster and without more pain. (From the syntactic point of view this is a step backward wrt. the Henderson's book showing how to compose graphics objects in Scheme...) You can't draw individual pixels. (OK, lines with length 1 work). So, impossible to create complicated textures. Impossible to generate complex geometric models rendered pixel by pixel. Try, please, to fill a rectangle with a texture. The graphic updates by the Draw monad will explode the memory quite fast. No relation between bitmaps and arrays. (If the bitmaps work at all.) Similar problems are visible in the Clean library. Both, Hugs and Clean libraries have been added ad hoc to the language environment. Plenty of horrible Windows quirks squeezed into a functional interface. What I mean by *intrinsic* graphics: The graphic primitives should be WELL integrated with the underlying virtual machine. No silly "external" bitmaps impossible to garbage-collect, and impossible to process (thresholding, transfer curves, algebra). No pixels drawn using "line". True, fast access to primitive data. Efficient 2dim and 3dim vectors, with optimized processing thereof. Mapped arrays, easy passage from screen to bitmap DContext. Possibility to have decent functional binding of OpenGL calls. And mind you, OpenGL is not just a bunch of graphic calls, but a "state machine". Some graphic data must be processed by strict algorithms, laziness may deteriorate the efficiency considerably. No, this is not JUST the problem of external libraries. It would be, if the language were at the level of, say, C. But if the runtime is complex with plenty of dynamical data to protect and to recover, and if the internal control transfer is non-trivial (continuations, private stacks, etc.) then adding efficient and powerful graphics <<ex post>> is not easy. === In my opinion one of best decisions taken by the Rice mafia was to base the DrScheme interface on WxWindows. What a pleasure to produce graphic exercises for students under Linux, test it under Solaris, and work with them under W2000 without a single incompatibility. I am still unhappy, because it is too slow to generate textures at a respectable rate, but no comparison with Hugs which bombs. But perhaps the next version (if ...) will optimize a few things. === And, if you want to have *interactive* graphics, then obviously you must provide some kind of event-processing functionalities. Is this just an external library question? ****************************** No place to discuss type systems here, but "falling back" into run-time checks is not enough in this context, we know that we need a genuine object-oriented genericity for graphical entities. Perhaps even with multiple inheritance or the java-style "interfaces". So, again, a bit more than just "graphic library". Jerzy Karczmarczuk Caen, France