[clean-list] Two questions (Types and graphics)

[Jerzy Karczmarczuk]

Could you please solve my homework?
Thank you!

I work with some math-oriented composite structures, vectors,
colours, differential forms, br!fg#kjgh$Łons etc., which belong to
Modules over a Field, which means that I can multiply them by a
scalar belonging to this field.

For example, I introduced some private 3D vectors

  :: Vec a = V !a !a !a


with all the standard vector arithmetic:


  instance zero (Vec a) | zero a
   where zero = V zero zero zero
  instance ~ (Vec a) | ~ a
   where ~(V a b c) = V (~a) (~b) (~c)
  instance + (Vec a) | + a
   where
     (+) (V a b c) (V x y z) = V (a+x) (b+y) (c+z)

etc. etc. I had no specific problems until I decided to
use a constructor class

  class (*>)  infixr 7 t   :: a (t a) -> (t a) | * a

this operator enables the multiplication of a vector (in generic
sense) by a scalar upon which the vector is built. For example

  instance *> Vec where
    (*>) s (V a b c) = V (s*a) (s*b) (s*c)


==

I defined a linear interpolation operator:

  linterp i0 i1 t 
   | t<zero = i0
   | t>one = i1
   | otherwise = (one-t)*>i0 + t*>i1

and I put it into the main module, in order to request from the compiler
its type. You, guru folks do the same, I see it from the fact that
plenty of your declaration and implementation modules have
trailing, useless semicolons in type declarations...

I got

  linterp :: (a b) (a b) b -> a b | * , - , < , one , zero b & *> a;

and using the marvelous lazy functional technique called cut-and-paste,
I transferred linterp into my shared library.

Then I recompiled the main module and its subsidiaries, and I got


Type error [Veclib.icl,87,linterp]: 
  "+" requested instance of the form (m a1 .. ak) is impossible

So, the Clean compiler does not accept the type produced by itself,
which I find I bit sad.

I suspect that libraries split in interface/impl modules are treated 
a bit differently than the main modules, but I never suspected seeing 
a difference at this level. The above declaration within the main
module is accepted.

What did I wrong? 
Well, finally I restricted the generic constructor type "a" to Vec and
it 
works, but I am not happy.

=======================================

A few other questions.

How to *READ A PIXEL* from a Picture?
Even simpler: how to read a pixel value from a bitmap?

I remember the answers of Peter Achten some months ago. Picture is
an output-only structure etc. Not sure, what a pixel is, etc. do
everything yourself. We would like to, not our priority, etc. 
Frankly, not very promising answers. 

I'll tell you what I tried concerning bitmaps. First I moved to a 
Windows (NT) machine. Then, I opened the file using openbitmap, 
and recovered the OsBitmap structure.

I got several pieces of data, for example the size, say, 284*281 
of my  BMP picture. And the {#Char} BitmapContent as well. But it 
is not directly usable.
 
I know, the data in a BMP and the pixel array are different things. 
I looked into pictCCall_12.icl, but from your inline codes one 
cannot learn anything. HDC is just an integer, the access routines 
are opaque. What can I do with the bitmapHandle? Where is the
palette? (Suppose I want to do some colour cycling.)

I know (more or less) the BMP file format. Shall I process the 
BMP contents by hand? It would be utterly silly, Windows did it 
for me. I checked as far as I could the Windows programming sections 
in IO lib, nothing found.

I wonder whether you have ever documented this low-level side of 
Clean IO programming in order to ENABLE OTHERS TO DO SOME WORK? 
I have plenty of ambitions here, but I am hopelessly stuck. 
Probably I could do a lot of investigation myself, but my age of 
retiring is approaching...

I have the impression - hopefully false - that you decided 
consciously to *hide* the "input access" to graphical structures.
For goodness sake, WHY? I would like to do some image processing
in Clean. Better, I think that functional languages are simply
ideal to do some serious work on texture generation. 
Mapping,
Warping,
Morphing, ...  -- all this is <<par excellence>> functional. 

Why don't you use some DLLs instead of your inline codes? It
might then be easier to make it more portable.

===

Once more, I am not asking that you change Clean, that you rework
its libraries just for my satisfaction. Tell me how what can I do
something myself. Shall I master htoClean? How can I save pictures
on a file?

I am still attached to Clean because it had decent graphics when
Haskell had none. I scanned the Game library, thinking that I might
find some low-level goodies for the general (low-level) graphics.
But I am now already a bit tired...

Best regards
Jerzy Karczmarczuk

Caen, France