[MLton] Stack size?
Wesley W. Terpstra
wesley@terpstra.ca
Fri, 8 Jul 2005 17:52:50 +0200
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