[MLton] Stack size?

[Matthew Fluet]

On Fri, 8 Jul 2005, Wesley W. Terpstra wrote:
> On Fri, Jul 08, 2005 at 04:08:07PM +0200, Wesley W. Terpstra wrote:
> > I'm trying to figure out how best to use epoll&kqueue in MLton atm
> 
> Ok, the fact that Socket.sock_desc = PosixPrimitive.file_desc = datatype
> makes it a real pain to squeeze the file descriptor out to the FFI.
> Is there some sort of 'best practice' for doing this outside of the basis?

I don't think there is a standard practice for that sort of exposure.  
Once a type becomes abstract, you hope you won't need its representation 
any more.

> Or should I simply lobby to have epoll and kqueue exposed in yet another
> MLton.YourSyscallHere?

That is a possibility, but I agree that MLton.* is getting a bit ad hoc.

A better solution might be to introduce a MLton.Reps or MLton.FFI.Reps 
structure, along the lines of:

signature MLTON_REPS =
  sig
     structure Socket :
       sig
          val packSock : int -> ('af, 'sock_type) Socket.sock;
          val unpackSock : ('af, 'sock_type) Socket.sock -> int;
          val packSockDesc : int -> Socket.sock_desc;
          val unpackSockDesc : Socket.sock_desc -> int;
       end
     structure Posix :
       sig
          structure FileSys :
            sig
               val packFileDesc : int -> Posix.FileSys.file_desc;
               val unpackFileDesc : Posix.FileSys.file_desc -> int;
               ...
            end
          ...
       end
     ...
  end

This is, of course, an unsafe interface, but it would allow exposing the 
OS/FFI representation of system objects for use with FFI calls.