[MLton] filedes = int (was: Stack size?)
Mon, 11 Jul 2005 16:33:47 -0400 (EDT)
> > > 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.