[MLton] bool and MLton FFI

[Matthew Fluet]

>> So, unlike int32_t and friends, there is no required size for a bool.
> ...
>> Point being that there may not be a universal choice for the
>> representation of 'bool'.
>
> Like Wesley, I don't see that we need a universal choice.  It's no
> different than C int, which varies from platform to platform.  All we
> need is to express the size on each platform so that we get the
> calling convention right.

But, we don't have this information readily available in the compiler 
proper.  The c-types.sml bindings are all handled by the Basis Library, 
implicitly brought in by TARGET_ARCH and TARGET_OS.  So, the compiler 
proper never knows the size of a C int, it just verifies that every FFI 
_import uses Int8.t, Int16.t, Int32.t, or Int64.t.

The point is that either in the elaborator or in the backend or in the 
codegen, the compiler is going to need to know the size of a C bool and 
then it is going to need to coerce from whatever representation it has for 
an ML bool.

I think there is a distinct difference between C 'int32_t' being the same 
as ML 'Int32.t' and trying to support C 'bool' being the same as ML 
'bool'.

>> Furthermore, equating ML 'bool' with C 'bool' would seem to rule out
>> a bit array implementation, though it does admit a word8 array
>> implementation.
>
> How we represent bool vector is a separate issue.  I think we should
> have bool in the FFI, but not bool vector.  That lets us represent
> bool vector however we want.

If you represent a bool in bool vector differently than a bool in an 
_import argument, then somewhere a coercion is happening, and so they are 
not the same type.  I'm just arguing that if they have different 
representations, then they ought to have different types.  A C 'int32_t' 
and an ML 'Int32.int' have precisely the same representation, so they can 
be considered the same type.

> This is heading down the road of making SML bool different than C
> bool, and requiring manual conversions on the SML side.  That's not so
> bad, and having the types be different means that the user can't
> forget the comparison with zero.

I think this is a better choice, though I still think that having neither 
C 'bool' nor ML 'bool' in the FFI would be the cleanest.

> But it could be simpler to drop C_Bool, use SML bool in the FFI, and do 
> the conversion automatically.

I just don't like treating SML bool so specially.  I like thinking of SML 
bool as nothing more than
   datatype bool = true | false
(although I know the Definition gives it slightly more priviledged 
status); we don't let any other 'datatype' in the FFI, arguing that we 
want to be free to make representation decisions.

> Although we still need some way to tell the codegen about the size of
> bool so it can use the right calling convention.

It's not clear to me that this is so easy to get into the compiler.