[MLton] x86_64 branch on AIX

[Matthew Fluet]

>> However, note that MLton treats the ML type 'char' as signed.
>
> This seems slightly odd given that chars are isomorphic to the
> nonnegative integers from 0 to 255.

Well, it's kind of inconsistent.  On HEAD, we have the following:

runtime/types.h:
typedef Word8 Char;

mlton/elaborate/elaborate-core.fun:
structure Type =
    struct
       open Type
       ...
       val nullary: (string * CType.t * Tycon.t) list =
          let
             ...
          in
             ...
             @ sized (Tycon.char o CharSize.fromBits,
                      let
                         open CType
                      in
                         [Int8, Int16, Int32]
                      end)
           end
basis-library/misc/primitive.sml:
       structure Char =
          struct
             open Char

             val op < = _prim "WordU8_lt": char * char -> bool;



>> So, if you have:
>>    val f = _import "f": char -> char;
>> then MLton will generate the following C prototype:
>>    int8_t f(int8_t);
>> and will compile the call to 'f' according to the C calling convention for
>> this prototype.
> ...
>> But, we might point out on the FFI documentation page that the
>> ML type 'char' is the C type 'signed char'.  The default C type 'char' is
>> available as C_Char.t, under either an INTEGER or WORD signature
>> (depending on the signedness).
>
> Is there any reason why we shouldn't have the "char" ML type expand to
> C_Char.t?  Or does that just encourage laziness and avoid what should
> really be done, which is to always use the C_*.t types when using the
> FFI.  I guess there's also the same issue as with bools in getting the
> information to the compiler.

Not allowing ML 'char' in the FFI will really hurt (more than not allowing 
ML 'bool'), because it means that one needs to coerce ML 'char vector' to 
ML 'C_Char.t vector' before allowing it in the FFI.  That's really 
expensive.
If we wanted to be more subtle, we could disallow ML 'char' in the FFI, 
but allow ML 'char' in an indirect type, like 'vector'.