[clean-list] Re: Clean 2.0 compiler // and graphics//

[Jerzy Karczmarczuk]

John van Groningen :

> There are recently more people who download Clean for linux than Clean for
> the mac, but a few years ago this was not the case. Therefore we already have
> an implementation of Object IO for the mac, and not for linux. And it is a
> lot less work to port ObjectIO 1.2 to the mac if you already have Object IO
> 1.1 for the mac, than it is to completely implement Object IO for linux. Also
> there is still not a single standard gui toolkit for linux. If we would
> choose the wrong one, we probably have to start over again in a couple years.

First, I am the last one here who would like to make nasty comments about 
the availability of Clean 2.0, etc. You have done a terrific job, and I am
personally very grateful. Your priorities are your priorities, and we, the
users cannot really change them easily.

But - please, with my full respect - your last sentence is not really serious,
it is something of the kind:
   "... weelll, I didn't marry, because I didn't find an *ideal* woman.
    You just imagine what would happen if I had chosen a wrong one, I would
    have to restart all over again in a couple of years/months/minutes..."


You did a lot in order to screen the user from the dirt of Windows APIs
(although you didn't screen me, I am still fighting with bitmaps. What
a mess...).

Why don't you try to get *any* GUI toolkit which proved its efficiency and
extensibility and portability? The eventual conversions will not be as huge.

I have a few complaints about the wxWindows, sure, but it is there, it works,
and it contributed to the undisputable and remarkable success of DrScheme
package. Why not this one?

Why not GTK or anything that is already in use? The basic graphic layer
under Linux is less messy than Windows.

Your O-IO for Windows is a slave of their api's. In a sense the functional
soul is lost completely [[side remark: exactly as within the Hugs Graphics
Library of Alastair Reid]]. 

In Hugs graphic commands constitute an imperative sequence of primitives
under the monadic "do". In Clean you do the same, only you update unique
Picture iteratively. Actually, this is not encouraging, for people who
dream of doing some functional graphimagery work. No real motivation to
do graphics in a functional language.

Personally I would like to *compose graphic objects*. To fill bitmaps
through array comprehensions. To have the programming power which you
can inspire yourself from the Metafont/Metapost fascinating codes.

Are you acquainted with archetypical image processing packages, like
Photoshop, PaintShop, Gimp, etc.? What holy gymnastics with layers, 
channels, masks (put into channels for lack of other means), what silly
image algebra is present *everywhere* there... All filtering business
is done at the level of concrete pix-matrices.

*I assure you* that all that and more, the texture generation, 3D effects
for 2D images, etc. are typical functional, often higher-order algorithms.

I truly believe that this is the direction which should be followed by
people who want to offer new qualities in this domain. It is *NOT* the
lowest-level graphics which will make Clean or Haskell more popular, but
rather the generational and transformational high-level utilities. So, take
for the lowest level anything, anything that works.

Or, as other said - fulfill your promise to open-source the compiler,
perhaps people will help you then, I imagine that we shall find several
people interested in plugging in the OpenGL libraries, etc.

Best regards.

Jerzy Karczmarczuk
Caen, France