[MLton] MLTON_THREAD

[Stephen Weeks]

> I thought that
>   structure Ready : sig type t end
> we a bit much, and "_t" made the connection that ready_t was related to
> 'a t.

I figure being in the same module establishes enough connection.

I don't mind Ready.t, and might even prefer it.  It's not really any
harder to read or write, and follows our convention.  It almost always
bites me at some later point if I don't follow it.

> > I like the prep* functions.  Another possible naming choice is ready*,
> > since ready is actually a verb.
> 
> I went with ready* initially, but virtually every threaded application
> implements a ready queue and uses "ready" as the function to enque a
> thread.  And prep[are] is a verb.

Yeah, it was partly the abbreviation I objected to.

> Given this, I'm tempted to go back to your earlier suggestion of
> type runnable, which would make ready* functions a less obvious choice,
> and seems natural with prep[are a thread to be run]* functions.

I slightly prefer Runnable.t to Ready.t.

> Another choice:  type active  and  activate*

I don't like "active" because it connotes that the thread *is* running
as opposed to being ready to run.


I'm thinking that the common case will actually be prepVal, and that
with prepVal already defined, then prep is not really needed.  Putting
it all together, how about the following?

	val prepare: 'a t * 'a -> Runnable.t
	val prepareFn: 'a t * (unit -> 'a) -> Runnable.t