[MLton] bool and MLton FFI

[Stephen Weeks]

I think we're getting close.  Here's my current understanding.

Exposing bool in the FFI means that either SML bool must have the same
representation as as C bool or there must be a conversion between the
representations.  Making the representations identical is a bad idea
because SML bool is always one of two values, whereas C bool could
take on more values depending on the size of the type.  So, one is
forced to do a conversion unless one wants to impose a severe
constraint on the SML representation of bool.  

Conversion between representations can be done either manually or
automatically.  Manual conversion is easily accomplished by exposing a
C_Bool structure with a (platform-dependent) type and conversion
functions.  Automatic conversion requires getting information about
the size of C bool into the compiler.  It seems easiest to me to get
this information to the elaborator, and have it insert the coercions,
so the rest of the compiler doesn't have to worry about it..  I don't
think it would be hard to put the size in the per-platform "constants"
file, which is already automatically built on each platform and is
used to supply other platform-specific constants to the compiler.

I continue to think that the bool vector issue is a red herring.  If
bool is in the FFI but bool vector isn't, then the only place the
conversion has to happen (either manually or automatically) is on the
bool type.  Once the C bool is converted to an SML bool, the
right stuff will just happen if that bool is put in a bool vector.

So, here are the options.

  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 dislike (1) because it forces programmers to write C wrappers for
functions that deal with C bools.  It's always good to avoid C.

Both (2) and (3) address this problem, at different levels of
implementation complexity.  (2) can be implemented with very little
effort and no compiler support.  (3) requires a small amount of
compiler support.  I think (2) will be slightly counter-intuitive to
users, because all the other C types in the FFI have an SML type they
are equivalent to (even C int is equivalent to some SML int type, even
though it changes from platform to platform).  I think (3) is more
intuitive, although I agree that the conversion is special and not
done anywhere else.  I view the conversion as making the outside world
look nice to SML (converting everything so we can deal with the nice
bool datatype) rather than exposing SML bool to the FFI.