[MLton] Stack size?

[Wesley W. Terpstra]

On Fri, Jul 08, 2005 at 11:06:59AM -0400, Matthew Fluet wrote:
> > 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.

This would be useful for a large number of applications I think.
File descriptors are the most important type here, but there are others...

MLTON_FFI =
  sig
    structure ISOC :
      sig
        structure Char : INTEGER
        structure Short : INTEGER
        structure Int : INTEGER
        structure Long : INTEGER
        structure LongLong : INTEGER
        structure UChar : WORD
        ...
	structure Bool : ???
      end
    structure POSIX :
      sig
        structure Socket : INTEGER
        structure FileDescriptor : INTEGER
        ...
        val unpackSocket: Socket.sock_desc -> Socket.int
        val unpackFileDescriptor: Posix.FileSys.file_desc -> FileDescriptor.int
        ...
      end
  end

After all, if you guys ever do port MLton to 64bit, then MLton programs are
going to need a way to call C functions where the sizes vary between targets.

Things like 'long myfun(long a, long b)' will not cleanly matchup with Int32
or Int64, but MLton.FFI.CTypes.Long.int. Or do you intend that MLton's 'long' 
will always match C's 'long'? That would be an alternative.

I think it's probably safe to say that a file descriptor will always be an
int, but why depend on that? I only think this is a safe assumption because
years of UNIX C API cruft pretty much guarantee its immutability. ;-)

There might be several other types that belong here too...
I think it a shame how there's crap like wordToPid in the basis library.
Also, SML just assumes that uid, pid, gid, etc are all SysWord.word.

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.

-- 
Wesley W. Terpstra