[MLton] OpenGL (currying + library guidelines)

Mike Thomas mike.thomas@paradigmgeo.com
Wed, 27 Jul 2005 12:23:53 +1000

Hi Anoq,

Good to hear from you again and especially as I'm lookig forward to seeing
someone take up the MinGW32 MLton port.

You wrote:

| I stumbled on this mail, sorry if my answer is obsolete, but
| it also contains some guidelines which might be useful in general.
| Mike wrote:
| > Stephen wrote:
| > |   * using tupled arguments
| > |   * renaming values (dropping the redundant prefixes)
| >
| > I also like the idea of curried functions as it makes function
| application
| > easier to my Haskellised way of thinking - I may be missing
| something about
| > how SML people work with curried functions though, as I'm not very
| > experienced with SML.
| I would also _strongly_ recommend using tupled function types.

One thing I purposely didn't mention in my earlier responses (avoiding more
work for myself) is that some parts of the OpenGL binding (GL and GLU, but
not GLUT) do have both curried and uncurried functions exposed, for example:

       val c_glViewport : int * int * int * int -> unit
       val glViewport : int -> int -> int -> int -> unit

where the direct FFI tupled function is simply named with a "c_" prefix.

I was just pressed for time during the GLUT phase and didn't want to
encourage anybody to ask for more!


Mike Thomas