[MLton-devel] Callbacks

[Matthew Fluet]

> Some work could be done on the C-side, as the set-up and execution of an
> ML call is a little burdensome.  Furthermore, implementation details leak
> through.  As can probably be ascertained from the C-code above, the
> implementation is essentially a collection of global locations used to
> pass parameters back and forth between C and ML.  On the C-side, we set up
> the arguments with
>   MLton_Callback_setI(index, arg);
> make a call with
>   MLton_Callback_call(name);
> and fetch return results with
>   MLton_Callback_getI();
> We could either provide a collection of common calls or maybe it's
> possible to use varargs to get a general solution.

The vararg solution was surprisingly simple.  Now the client code looks
like:
void f () {
	Int x;
	fprintf (stderr, "f() starting\n");
	fprintf (stderr, "calling SML: A(1,2)\n");
	MLton_Callback_call("III", "A", 1, 2, &x);
	fprintf (stderr, "done calling SML: A(1,2) = %i\n", x);
	fprintf (stderr, "calling SML: B('x', 3)\n");
	MLton_Callback_call("CII", "B", 'x', 3, &x);
	fprintf (stderr, "done calling SML: B('x', 3) = %i\n", x);
	fprintf (stderr, "f finished\n");
}
with
  int MLton_Callback_call(char *rep, char *name, ...);
The  rep  argument describes the type of the SML function.  Currently, I'm
using the int return to indicate that the  rep  is well-formed (i.e., only
made up of B,C,I,U,R,W for bool, char, int, unit, real, word); we could
use it for indicating failure on the ML side.

On the ML side, Callback.Type.make constructs the string it expects the C
side to use as the rep.  When the call from C is handled, I first check to
see if the expected rep equals the actual rep -- this gives a minimal form
of dynamic type checking.  Currently, if there is a type mismatch, we
raise an exception (which can only be handled by the top-level handler),
which can't be recovered from by a user.  An alternative would be to
return to C with an error-code set, which would be reported via the return
value of MLton_Callback_call.



-------------------------------------------------------
This SF.net email is sponsored by: If flattening out C++ or Java
code to make your application fit in a relational database is painful, 
don't do it! Check out ObjectStore. Now part of Progress Software.
http://www.objectstore.net/sourceforge
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel