[MLton] bool and MLton FFI

[Matthew Fluet]

>> I disagree here. We should start encouraging users to use _import
>> like this:
>> 	_import "foo" : C_Int.t * C_Long.t * Int32.t-> C_Bool.t
>> for the function:
>> 	extern bool foo(int x, long y, int32_t z);
>> Otherwise their code won't be portable.
>
> This is naive. No realistic libraries provide functions like that.

Everything in the standard C and posix librarys are functions like that.

> Real library API's look like:
>
> 	GLint GLgetStatus(GLint);
>
> which means if you're trying to model the C function correctly
> in a portable manner, you have NO choice other than to provide
> conditional compilation, and to prevent combinatorial explosion
> you must ALSO provide the ability to define aliases (recall
> OpenGL has hundreds of functions in the API). So you would write:
>
> 	_import "GLgetStatus": GLint -> GLint;
>
> having preceded it by (something like)
>
> 	#if _WIN32
> 	#type GLint = int
> 	#endif

This is all perfectly well supported by the FFI and MLB systems; it might 
be slightly more verbose than a pre-processor, but we're providing an ML 
compiler, so if you want to program in C, you pay a little syntactic cost. 
In any case, here is how your example would be handled:


gl-types.x86-linux.sml:
------------------------------------------------------------
structure GL_Int = C_Int
------------------------------------------------------------

gl-imports.sml:
------------------------------------------------------------
val getStatus = _import "GLgetStatus": GL_Int.int -> GL_Int.int;
------------------------------------------------------------

gl-imports.mlb:
------------------------------------------------------------
local
   $(SML_LIB)/basis/c-types.mlb
in
   gl-types.$(TARGET_ARCH)-$(TARGET_OS).sml
   gl-imports.sml
end
------------------------------------------------------------


This is precisely how we handle things like 'mode_t', 'uid_t', and 
'gid_t', which don't have a fixed size across platforms.