[MLton] ffi improvements

[Daniel C. Wang]

I don't think it causes any problems per-se, I just don't like not having as 
much type checking as what is avalible in the C prototypes.

Consider..

char *f(void);
void g(int *p);

The MLton native wrappers would have the type

val f: unit -> MLTon.Pointer.t
val g: MLTon.Pointer.t -> unit

So I could do the following with the MLTon wraper functions

  g(f())

which the C compiler would have prevented me from doing. The MLTon FFI is 
forcing me to throw away info that's in the C code.

Also, it seem using the MLTon.Pointer structure I can do the following
val p = ... (* word alligned pointer)*

MLton.Pointer.getWord32(MLTon.Pointer.add(p,0w1));

which I suspect will cause an unaligned access error on many RISC platforms.

I suspect what I want is a slightly more refined interface for the user. I 
don't see any problem having a Pointer type in the compiler, but I would 
expect more type-checking in the exposed user interfaces.


Stephen Weeks wrote:

>>BTW what's the story with enforcing alignment restrictions.  It's
>>not the case that the C types char* and int* are semanticlly the
>>same because of potential alignement constraints, but the MLton FFI
>>maps them to the same Pointer.t which I think is wrong.
> 
> 
> Can you explain how this prevents writing a certain program or causes
> other problems?