You know, I could really easily grow to hate exceptions.
For one thing, wouldn't it be nice to have an engines style interface for
timelimit? I.e., if it runs out of time, I may want to let it have more time
later.
Isn't it a bit strange to have threads `take' an argument but not return a
result? Between the two, I would think that returning a result is more
generally useful than taking an argument, but they both are nice.
Admittedly, what this means in the presence of callcc (so a thread might
return more than once) is a bit strange, but still. Certainly for engine
like things it is really desirable to get an answer back. I can, of course,
fake all this with refs, but that seems really ugly.
If you really want to have asynchronous exceptions, then you need a general
function raiseInThread with type
which will (asynchronously) raise the exception the next time the thread
argument is run. With this you can have an engine interface and still cause
the computation to clean up.
All of this gives me the shakes. Note horrible things will happen and they
will not be reproducible.
Most desirable change:
Make threads return a value. From the thread you can get the value (best
by returning a 'a option, NONE if the thread isn't done yet, not
quite as nice by having a separate test which returns a bool if the
thread is done).