[MLton] OpenGL

[Stephen Weeks]

> The second was that I am considering adding GL.cm, GLU.cm and
> GLUT.cm to deal with each of the corresponding pairs of SML source
> files (GL.sig, GL.sml and so on) - I thought this might be a way
> around the kludge I have used of #including GL.sig etc in
> ../glu/glu.sml and ../glut/glut.sml.

The seems reasonable to me if you ever need to have just one of the
libraries.  If you put the .sig and .sml in a .cm file and always
refer to that, MLton, just as CM, will make sure that the code only
occurs once in the program.

> If this is a workable method, then I would need to ask you (please)
> to manually remove from your CVS repository any evidence that
> "Gl.cm" or "GL.cm" ever existed to get around the Cygwin bug.

Done.


I have a few minor tweaks for Makefile, and one for spin_cube.sml.

Regarding the Makefile, wouldn't it make more sense to pass GL_c.o and
GLUT_c.o to each call to mlton instead of using GL_c.c and GLUT_c.c?

You have a lot of calls to "mlton" that should be to $(mlton).

To keep CVS quiet, I've found it nice to put all the stuff that you
currently have in your clean target into the .cvsignore, and then have
make clean use that file.  That way all the information about what's
junk is in once place.  You can have the clean target call our
bin/clean script, which is what we do in most of our other Makefiles.

Finally, I need to request a change to spin_cube.sml.  There need to
be type annotations (: Real32.real list) on the declarations of
whiteLight, sourceLight, and lightPos.  The latest MLton will actually
report an error if you don't have them.  The reason is that the new
(correct) handling of topdecs resolves overloading of constants on
those declarations before looking at the uses of whiteLight, etc,
which means that it resolves them as "real list", not "Real32.real
list".   So, the change is

val whiteLight: Real32.real list =  [0.5, 0.5, 0.5, 1.0]
val sourceLight: Real32.real list =  [0.8, 0.8, 0.8, 1.0]
val lightPos: Real32.real list =  [0.0, 0.0, 0.0, 1.0]

Another alternative would be to make sure there are no semicolons
(like the one on line 9) that cause the program to be split into
topdecs, although I'd prefer the annotations, which would be more
robust (and informative).