[MLton] The evils of importing as 'extern'

[Matthew Fluet]

> I needed to include basis-ffi.h in c-chunk.h in order to get prototypes for 
> WordS8_quot, because Word-check.h had methods which inferred an incorrect 
> type. This then later conflicted with the correct type signature that MLton 
> wrote in the c-codegen. By including basis-ffi.h, this problem was fixed as 
> Word-check.h no longer needed to infer the type, as the (correct) prototype 
> was already available.

I see the issue with the prototypes for WordS<N>_quot, but I wonder if 
this is the right solution.  It seems to me that there must have been some 
reson not to include "platform.h" in "c-chunk.h", which is where all the 
FFI declarations used to live.  On the other hand, including "basis-ffi.h" 
would ensure that MLton emits a declaration that is consistent with the 
actual runtime function.

Another solution would be to have Word-ops.h emit the declaration for 
WordS<N>_{quot,rem} when used with the C-codegen.

Yet another solution would be to switch back to the checked multiplication 
via coercion to a larger size; Unfortunately, this doesn't leave an option 
for handling 64-bit multiplication.

> However, now we have the problem that basis-ffi.h correctly defines 
> Real64_Math_e as a Real64_t. Unfortunately, the C codegen doesn't output the 
> type, just an 'extern Real64_Math_e;'. My original FFI changes output 'extern 
> Real64_t Real64_Math_e;' which would've worked here.
>
> Somewhere that code got lost in the argument about whether it was important 
> that _address also provide a correct type. I propose to resurrect this change 
> for _symbol. For the basis, at least, the type information which _symbol has 
> will suffice. _address can continue to emit 'extern X', though I personally 
> still think we'd have been better off if _address had included the pointed-to 
> type too.

Possibly, although I'd want to review the discussion we had.