[MLton] x86_64 port status

[Stephen Weeks]

> The issue, as I see it, is that "platform.h" has been serving too many 
> roles.

I agree that platform.h serves all the roles you mention.  I'm just
not entirely clear on the benefits of splitting them all up.

> However, I believe that reinstating libmlton.h, in the guise of the
> auto-generated basis-ffi.h, is better, as it ensures consistency
> between the C and ML sides of the Basis Library implementation.

That is a huge improvement.  So much so that I suspect users will want
us to make the tool available for their programs.

> Furthermore, I believe that it makes sense to auto-generate the
> sizes of C primitive types, which needed only a sane C99 environment
> and the utilities.

True.  Although it doesn't hurt to have more there when defining the C
primitive types.

> <cenv.h>:
> 1) attempts to establish a sane C99 environment:
...
> <platform.h>
> 2) identifies the target OS and pulls in a target OS specific header,
>     which (recursively) serves a number of roles:
>      a) attempts to compenstate for a broken C99 environment
...
> It would be nice to somehow move 2a) into <cenv.h> in some manner. 
> Stephen's suggestion of moving the #ifdef chain at the beginning of 
> 'platform.h' into 'cenv.h' is probably the best solution, though it 
> suffers from folding 2b into <cenv.h> as well.

It would certainly be possible to split out the n-way platform #ifdef
and the platform/<os>.[ch] files into two pieces, one piece that
extends the C99 part and the other for everything else.  But it seems
like a lot of work for no clear benefit to me.