[MLton] thread model

[Stephen Weeks]

> But there is no way to reify a MLton.Thread.t to a MLton.Cont.t.
> 
> I really depends on what kind of API Luke wants to provide.  

Makes sense.

> If it is the scheduler's discretion to create the restore point, then all
> it has in hand is a (suspended) MLton.Thread.t (and sometimes just a
> MLton.Thread.Runnable.t), then you need something else.

A suspended thread might be OK, since one could do some trickery with
prepend to throw to it and do the callcc.  But a Runnable.t defintely
requires runtime support.  So I see your point.  Thread.copy seems
like a sensible operation to have anyway.