[MLton] MLTON_THREAD

[Stephen Weeks]

> > 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
> 
> I disagree:
...
> [fluet@tiger core-cml 13]% grep prep * | wc -l
>      37
> [fluet@tiger core-cml 14]% grep prepVal * | wc -l
>      16
> [fluet@tiger core-cml 15]% grep prepFn * | wc -l
>       3

Looking more closely at core-cml, I see 10 preps, 16 prepVals, and 3
prepFns.

The difference is whether people mostly deal with threads that have no
context (as with preemptive threads) or threads that have some
context.

> So, I prefer:
> 
>  	val prepare: unit t -> Runnable.t
>  	val prepareFn: 'a t * (unit -> 'a) -> Runnable.t
>  	val prepareVal: 'a t * 'a -> Runnable.t

Another advantage of 

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

is that the interface is smaller.  I think that simplicity/uniformity
is nice.  Compare

	prepare t
	prepareVal (t, x)

to

	prepare (t, ())
	prepare (t, x)

With the lightweight anonymous function syntax of SML, I'd almost go
to just having a single function

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

But

	prepare (t, fn _ => ())
	prepare (t, fn _ => x)

looks a little to messy to me, and we both agree that prepareFn is
pretty uncommon.


I don't think it's a big deal either way, since most people would
use some higher-level threads package.