[MLton] Support for link options in ML Basis files

Stephen Weeks MLton@mlton.org
Fri, 21 Jan 2005 08:11:30 -0800

> Another difference I noticed is that you generally have
> your structures as SDLVideo, SDLEvent etc.
> I have packed mine fairly thoroughly into e.g.
> SDL.Event, SDL.Event.Mod, SDL.Event.Key, SDL.Surface etc.

This is a nice way of organizing things.  I'd like to see it taken to
the extreme, so that State, Keysym, ButtonMask, mutex, etc. all get
their own structures, which are substructures of SDL.  Then, in the
traditional MLton style, you can call all your types t and group the
operations in the module for that type.

> | and also have the same names as C where
> | there is no namespace management. For example, "GL.glVertex3d: real ->
> | real -> real -> unit" in CVS vs "GL.vertex3D: real * real * real ->
> | unit" in my bindings.
> It is one less translation to make in converting code from C sources to
> SML - easier for learners and less brain power diverted for those familiar
> with OpenGL when reading SML OpenGL programs.  I think it a good idea to
> retain the C names of the functions at the low level of this C library
> binding because ultimately the libraries are defined by their C
> implementation as reflected also in written descriptions of those libraries.

A nice way to organize things would be to start with a low-level
interface like Mike describes, with minimal renaming.  Although I
would certainly argue for tupling for a number of reasons (including
the facts that it corresponds more closely to C and saves writing
curried wrappers).  Such a library will be easier to a C programmer.
However, as many of our users will be more experienced with SML than
OpenGL, I think it is also essential to wrap the low-level interface
in a form that takes advantage of the SML's organizational abilities.
I.E. build a wrapper much like Anoq and Chris are doing, taken to the
extreme I suggested above (SML abstract types for C concrete types,
one type per structure, group functions in module for their type).

It will certainly be worth it in the long run for both OpenGL bindings
to get merged and for both SDL bindings to get merged.  Feel free to
add OpenGL and SDL pages to the wiki and to use this mailing list to
coordinate your efforts.  I can also add a lib/sdl directory to the
MLton CVS if that would help.

It would also be good if someone familiar with OpenGL and MLton/SML
responded to the question Joh Harrop asked on comp.lang.functional.