[MLton] C codegen and world* regressions

[Wesley W. Terpstra]

On Jun 17, 2006, at 10:49 PM, Matthew Fluet wrote:
> I don't know if that quite works, because I'm not sure that the  
> natural C representation of bool[] is necessarily equal to MLton's  
> representation of bool array.  In particular, we could turn it into  
> a bit-array, while I think C will make it a 8-bit char array.  So  
> you still have pin things down to what the C-side does.

C actually makes it a 32 bit array (absolutely horrible!).
I would absolutely love it if a future MLton represented 'bool  
vector' as a bit vector! :-)

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