Daan Leijen wrote:
[...] An attribute has both a type "a" and a thing that it belongs to "w". I wonder why the "thing it belongs to" is absent from your approach as it seems quite fundamental to me.
Of course there is a "thing it belongs to" for state variables in OpenGL, too: It's the current rendering context (= the big, fat OpenGL state machine), but it is implicit in all OpenGL calls. Handling the context is beyond OpenGL's scope and normally handled by a GUI toolkit, e.g. GLUT. You could do this e.g. under X11 with GLX calls like glXMakeContextCurrent, which associates a context with the current OS thread (Hello, FFI list! :-), but this is rather unusual. You normally have a single context per window, and that's it. Furthermore, switching an OpenGL context could be rather heavyweight, as it potentially involves a lot of "real world" state changes on your graphics card (reprogramming texture units, swapping of display lists, flushing rendering pipelines, etc.). So this implicitness was a rather intentional design choice when the OpenGL API was created and should not be re-introduced artificially afterwards.
It allows you for example to organise the attributes in type classes and re-use the same attribute name for different kind of things.
Hmmm, For the reason stated above, I don't think that there will be type classes in HOpenGL similar to the usual "has a label" stuff in GUI bindings.
[ some Haskell code for Attr, get, Prop, (=:), and set omitted ... ]
That's basically what Graphics.UI.GIO.Attributes does, or did I miss something?
Now, regarding openGL with state variables, you would make attributes that work on those, for example:
value :: Attr (IORef a) a value = Attr (getIORef) (setIORef)
So, even openGL will assign attributes to certain kind of things.
Nope, state variables in OpenGL have nothing to do with IORefs or something similar, they are entities from the current context (= state machine), and are not mirrored on the Haskell side. If they can be set, there is an OpenGL call to do that, and if they can be read, there is an OpenGL call retrieving that part of the state. If one or both of the calls are missing from the API, there is a very good reason for this. The "w" in GIO's API would always be "()" in HOpenGL, and should therefore be hidden from the latter API. Otherwise the types and calls would look rather strange, and people would start asking what this omnipresent "()" should mean. In types the "()" could be hidden by appropriate "type" definitions, in function calls the extra argument can be supplied by a wrapper function.
Furthermore, you can still make a read/write distinction by putting "get" and ":=" in classes as you do:
class Readable attr where get :: attr w a -> w -> IO a
class Writable attr where (=:) :: attr w a -> a -> Prop w
instance Readable Attr where ... instance Writable Attr where ...
You can't make a distinction with a single Attr type, you need different ones for readable, writeable and r/w attributes. It's crucial IMHO that you get a type error when you e.g. apply "get" to a write-only attribute.
But I am personally a bit hesitant to do this as it might give rise to rather complex error messages [...]
Better a complex error message at compile time than a simple one at runtime. :-) Seriously, I don't expect real problems if we stay within H98.
[...] Therefore, i am quite curious if the approach that is focused on "Attributes" as sketched in this mail will also work for openGL.
Despite my comments above, I think there is common ground: Doing some trivial impedance matching (nuking the "()") won't pose real problems in HOpenGL's case, so the question is: Can you fit the read/write distinction into GIO? BTW, I had a closer look at GLUT and OpenAL (something I really like to write a binding for, too) and found that the concepts in question would be rather beneficial for a Haskell API. OTOH, this should have been expected, because those APIs are closely modeled after OpenGL. Cheers, S.