[MLton-devel] RE: [MLton-user] new release of MLton

[Mike Thomas]

Hi Stephen.

| > I couldn't think of a way of actually passing those
| > callback functions as SML side function arguments to functions
| which in turn
| > call _ffi C functions to set callbacks, for example, setting a redraw
| > callback on the C side, but doing it entirely from the SML side.
|
| Ken Larsen described to us how they handle callbacks in mGTK
| (http://mgtk.sf.net).  Here's what he said.
|
.... GTK stuff cut....

|
| Would a similar approach for you?  I could imagine having different
| hash tables and dispatchers for different types of callbacks.

I can probably simulate the Moscow ML callback setting constructs by this
approach.  I'll need to think about it.  Having said that, it would be nice
for a games programmer (for example) to be able to work directly with the
metal, although to be fair, they wouldn't be using the GLUT callbacks and
event loop if they were serious.

I'm pushing for ease of use and transparency both for myself in terms of the
FFI and for the end user.  The original Moscow ML binding allows the SML
approach to the OpenGL libraries to be intuitively the same as the C
language bindings which are well known and well documented.  This gives two
advantages for the average person already familiar with OpenGL or who
already has a book on the subject:

1. It feels the same - less effort in switching to a nice language like SML
from C as the SML binding does not add an extra layer of effort in
translating preexisting code.

2. Any OpenGL binding I produce for SML compiler A give will be portable in
terms of end-user SML code to SML compiler B.

Here is some code - a direct and transparent translation of preexisting C -
each GL/GLUT function here is a direct FFi call to a C function:

open GL;
open GLut;

fun display () =
    (
     glClearColor 0.0 0.0 1.0 1.0;
     glClear GL_COLOR_BUFFER_BIT;
     glFlush()
     )

fun main () =
     let
	 val args = ["shortest"] @ CommandLine.arguments()
	 val argc = List.length(args)
     in
	 glutInit argc args;
	 glutCreateWindow "Short Test";
	 glutDisplayFunc display;      (* Register the display callback *)
	 print("Click the close icon to close the window.");
	 glutMainLoop()
     end

val _ = main();


| I am surprised that when you run make, you get no errors.

Sorry about that - the old trap of writing a bug report and tweaking the
example source at the same time.

| You are correct that you cannot put .c files into .cm files.  But
| there is no need, since you can link with .o files on the command
| line.  So, if you change dynlib.cm to
|
| 	Group is
| 	Dynlib.sig
| 	Dynlib.sml

Still it would be convenient.  Having said that I suppose there is a
compatibility issue with SML/NJ which presumably doesn't allow C source code
in CM files.

|
| and change your Makefile to
....


As usual, you've been very helpful.

Thanks

Mike Thomas.




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel