[MLton] bool and MLton FFI

[Stephen Weeks]

>  1. No bool in the FFI.
>  2. C Bool in the FFI with manual conversion to/from SML bool.
>  3. Bool in the FFI with automatic conversion between C bool and SML
>     bool.

I'm coming around to option (2) as well.

> there is the incongruity of allowing both 'Int32.int' and 'bool' in 
> the FFI, but not both 'Int32.int vector' and 'bool vector'.

I agree with this.

> it also makes C_Bool.t vector work insofar as Vector.map
> C_Bool.fromBool v works.

and with this.  These argue for (2) over (3).

> I don't think C bool is used that extensively.  All of the places I
> used Bool.t in basis-ffi.def, the C side really was an 'int'
> expression.

I agree with this; however, the problem still remains for those who do
use C bool that it is impossible to _import/_export without C
wrappers.  This argues for (2) over (1).

> 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.

Yes!

> Requiring them to use the C_Bool type for FFI is then not so unusual.
>
> The user-visible rule is: if it's not a fixed size, use C_X for type  
> X. You might need to convert types for int -> C_Int.t, but that's the  
> price you pay to interface with C.

This is a convincing argument.  Manual conversions for C_Bool are just
like manual conversions for integral types, which must be bounced
through LargeInt in order to portably get them to some other integral
type.  If we ever automatically do bool, we should do int at the same
time.  Or perhaps some higher-level stuff (using Fold?) can be built
in pure SML.


With this approach, we get both portable C calls and (after manual
conversion to Int or IntInf) portable SML code, independent of C
compiler integer sizes.