[MLton] C codegen and world* regressions

[Matthew Fluet]

>> Would removing bool from the FFI types be a horrible idea?
>
> If you promise to make it a bit vector, I wouldn't be devastated to see it 
> disappear from the FFI.
>
> OTOH, as long as it's documented to be a bit vector, then I don't see how 
> that would be a problem..? It just wouldn't be the case that a MLton bool is 
> a C bool. However, I think that's going to be the case with 'int' now too, 
> right?

I think the issue is that we would like the representation of a bool 
vector to be a choice, rather than a requirement.

And you are correct that an ML 'int' is not necessarily equal to a C 
'int'; what we promise is that an ML 'Int32.int' is equal to a C 
'int32_t', etc.  To make things a little easier in the ML type-checker, 
the elaboration of FFI constructs is allowed to 'peek through' an opaque 
signature match to see the underlying base representation.  So, the 
default behavior will allow an ML 'int' to be used in FFI constructs, and 
it will be an 'int32_t' on the C side.  If you compile with '-default-type 
intinf', then the type checker will complain.  The problem is that if you 
compile with '-default-type int64', then the type checker won't complain, 
but MLton will send the value over as an int64_t, which might not be what 
the C-side is expecting.

>>> I wonder if the right thing to do for situations where we are unsure
>>> or have C functions that return int instead of bool, is to expose them
>>> as int in the FFI and convert the int type to bool in SML code with a
>>> comparison to zero.
>> 
>> If we disallowed bool in indirect FFI types (i.e., bool ref, bool array, 
>> bool vector), I could imagine implementing this as a type directed 
>> elaboration of FFI functions.
>
> I feel pretty uncomfortable with the prospect that FFI functions returning 
> bool need to carefully return either 0 or 1. While I agree with Stephen that 
> we can define it however we want, I think that the average C programmer 
> expects to be able to return the result of a C test as a bool. So, however 
> it's implemented, I think that comparing to zero is definitely a good idea.

I agree that its a violation of the principle of least surprise.  I'd be 
most happy with removing bool from the FFI.  We don't use it that heavily. 
As best I can make out, there has always been this undefined behavior with 
respect to bool in the FFI, and nobody has ever complained, so I'm 
guessing that bool isn't used that much.