[MLton] filedes = int (was: Stack size?)

[Matthew Fluet]

> > > A better solution might be to introduce a MLton.Reps or MLton.FFI.Reps 
> > > structure, along the lines of:
> > > 
> > >           val packSock : int -> ('af, 'sock_type) Socket.sock;
> > >           val unpackSock : ('af, 'sock_type) Socket.sock -> int;
> > 
> > Anyways, I certainly agree that something in MLton to unpack the basis types
> > for use in the FFI is the right thing to do in the long term.
> 
> However, I now have a better idea than my previous suggestion:
> - datatype sock = S of Prim.sock
> + type sock = Prim.sock
> 
> After all, this is going to be protected by the signature anyways.
> The only place where this will make a difference is the FFI (?).
> ... which is exactly where we want it to be an 'int'.
> 
> Also, the same goes for posix file descriptors:
> -       datatype file_desc = FD of int
> +       type file_desc = int
> 
> I understand that _inside the basis_ there is a loss of abstraction, but in
> this case I think the benefit (FFI friendly descriptors) outweighs the small
> chance of confusion about the nature of that particular integer.

The fact that sock and file_desc are implemented by datatypes partially
arose from the fact that for quite some time, MLton had a very incomplete
front-end type checker.  Datatypes, requiring a wrap/unwrap at their uses
(and, hence, handled by even the most primitive type-checker) provided
better abstraction than signatures.

Now that there is a complete front-end, we could acheive the same by

-	datatype file_desc = FD of int
+	structure FD :> sig type t end = struct type file_desc = int end
+	type file_desc = FD.t

Now the type checker will prevent any accidental use of file_desc as an 
int, with the one exception being that the file_desc may escape through an 
FFI call (where it will be treated as an int).

> PS, there is a bug in OS.Process.sleep: it sleeps too short.
> Once the sleep time drops below 1s, it returns immediately.
> 
> I admit that the basis specification does not say you must guarantee to
> sleep at least as long as the parameter, but that is standard UNIX...

We are calling the POSIX function "sleep", so you would get the same 
behavior with a C program.