11.5.1  Overview

THE OPENGL BINDING IS NOT YET OPERATIONAL; PLEASE IGNORE THIS SECTION FOR NOW.

Providing a production-quality Opengl binding in Mythryl cannot be done simply by providing one-to-one bindings to the Opengl C functions:

• Mythryl has better namespace management than C, and consequently has no need to add a clumsy opengl_ prefix to every identifier.
• Mythryl and C have different conventions for use and meaning of upper-, lower- and mixed-case identifiers; a production-quality Mythryl binding needs to respect the Mythryl conventions.
• Mythryl provides both tuple and record arguments to functions; a production-quality interface needs to select between them to appropriately maximize type-safety and convenience.
• To provide Mythryl levels of type safety, enum datatypes need to be defined in place of Opengl integer constants like GTK_ARROW_UP, and the interface reworked to use them.
• Mythryl’s convention for handling possibly NULL arguments is different — and safer.
• Mythryl has true closures, allowing simplification of the callback interface.
• Unlike C Mythryl has lists, which the interface needs to take advantage of as appropriate to improve type safety and application programmer convenience.

The Mythryl Opengl binding provides two interfaces intended for use by the application programmer:

• Easy_Opengl, which makes common simple GUI interfaces particularly easy to construct.
• Opengl_Client, which provides more complete and flexible access to the underlying Opengl library functionality.

The Easy_Opengl interface is defined by src/opt/opengl/src/easy-opengl.api; the Opengl_Client interface is defined by src/opt/opengl/src/opengl-client.api.

The Opengl interface uses tuple or record arguments to a function according to a simple rule:

• If all parameters to the function have different types, a tuple argument is used.
• Otherwise, a record argument is used.

Using tuple arguments when all parameters are of different types maximizes convenience without loss of type-safety; any mis-ordering of arguments will result in a compile-time type error.

Using record arguments when multiple parameters of the same type are present minimizes the risk of mis-ordering arguments to produce an error which cannot be caught at compile time.