BAL paper available >> graphic libraries

[Jerzy Karczmarczuk]

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