[HOpenGL] Re: [Haskell] ANNOUNCE: OpenGL 2.3.0.0

[Sven Panne]

[ Thread moved to HOpenGL mailing list ]

Am Freitag, 31. Juli 2009 22:43:14 schrieb Paul L:
> [...]
> I've also noticed that the decision was made to use solely C types as
> instances for VertexComponent, ColorComponent, etc. I'm not sure I
> understand this change because:

First of all I have to admit that I'm guilty of leaving out this change from 
the change notes, sorry for that.

> 1. There was no default type for things like GL.Vertex3, and one had
> to explicitly annotate the type. Removing Int, Float from the
> Component classes would surely break A LOT OF existing code.

Strictly speaking, it breaks only code which was wrong, anyway. The OpenGL 
spec itself makes e.g. only assumptions about minimum sizes of the types, but 
prescribes no specific mapping. Granted, GLfloat e.g. has been a type synonym 
for Float, but there was never a guarantee for that and I consider the usage 
of type synonyms for this an API bug in previous versions of my package. 
Fixing code which breaks is quite trivial and those fixes will make any non-
portable assumptions explicit (via fromIntegral, realToFrac or castPtr), which 
is a good thing, and the way it should have always been.

In your example above, the type annotation should be ':: GLfloat', not ':: 
Float', which worked only by accident. If you have a 'Vertex3 Float', use 
'fmap realToFrac' to get a 'Vertex3 GLfloat'.

> 2. I don't see a problem adding back Int, Float, Double, etc. as
> instances of those Component classes along side of C types.

What GL type should be used for Int? Answer: We don't know, and perhaps there 
isn't even one. Same for the other types...

> On the other hand, I'm comfortable with changing types like GLint to C
> types, as existing code should have used GLint instead of Int.

I want to go even one step further and change the GL type synonyms into data 
type renamings, including their common instances (Num, Ord, etc.), of course. 
This is the cleanest way of handling things, and it is easily possible to 
write code that works with the old type synonyms of Int32 and friends, the 
current synonyms for CInt and friends, and the future newtypes. Just make any 
assumptions explicit via fromIntegral/realToFrac/castPtr/...

I'm sorry for any code breakage, but I feel that this is the right way to go, 
and I hope that other people will agree. Anyway, I'm open for discussions...

Cheers,
   S.