[MLton-devel] FFI in user's guide

[Stephen Weeks]

> The user's guide says that the grammar for types allowed in ffi are:
> 
> ty ::= u | t * ... * t -> u
> u ::= bool | char | int | real | string | unit | word | word8
> t ::= u | u array | u ref | u vector
>      | CharArray.array | CharVector.vector
>      | IntArray.array | IntVector.vector
>      | Int32Array.array | Int32Vector.vector
>      | RealArray.array | RealVector.vector
>      | Real64Array.array | Real64Vector.vector
>      | Word8Array.array | Word8Vector.vector
>      | Word32Array.array | Word32Vector.vector
> 
> I don't think that string belongs in u.

Agreed.  I guess it belongs in t like all the other vectors.

> (I was thinking that Callbacks should support a type grammar that is
> the "inverse" of FFI, but was having trouble with thinking about
> passing a string from C to SML.)

meaning  ty ::= u * ... * u -> t?  

Thinking about exporting constants, I guess we could allow that too,

	_export "x": int; 13

where with this there is no need to use callFromC handler.

> In the presence of Callbacks, we might want to be able to register roots
> with the GC; certainly, if C calls to SML while holding onto a (t - u)
> type, that pointer might well change while SML is executing.

Agreed.  The first implementation that comes to mind is to have the
runtime keep a doubly-linked list of heap pointers that it uses as
roots and updates after every gc.  Registering a root adds to the
doubly-linked list and unregistering removes from the list.



-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
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