[MLton] Non-exhaustive exn fn match

[Vesa Karvonen]

Quoting Stephen Weeks <sweeks@sweeks.com>:
> > True, but then you have to depend on threads and pay (possibly significantly)
> > for the critical section. 
> 
> You only have to depend on threads if you want threads.  If you
> don't use threads, you don't need the critical section.

Perhaps I wasn't clear enough. What I was thinking about is that the
implementation of the UT would either A) use some critical section procedure
(like MLton.Thread.atomically), which can reduce portability, or B) not use a
critical section, which means that the code wouldn't be thread safe. Either
way one has some interesting times ahead (portability problems / nasty bug).

>  I think we in
> fact even used to have an optimization in MLton to turn
> atomic{Begin,End} into no-ops for programs without threads.  Sadly, I
> think that optimization went by the wayside.  So, I guess you're
> right, you do have to pay some.  But the cost is only a couple of
> instructions.

I wasn't really referring to any particular thread implementation. The
cost would increase significantly if the thread implementation supports
true parallelism and you actually have multiple processors.

> > It is much better to just avoid unnecessary shared state, IMHO.
> 
> Maybe.  I don't know whether the ref-cell approach (even with critical
> sections) or exn-based approach will be more efficient with MLton.
> Some tests would say.

I would expect that the performance of an exception based solution would
always be good enough. A ref-cell based solution with a critical section
could totally kill performance in a worst case scenario.

Overall, I would expect to spend much more time maintaining a solution
based on ref cells.

(Off to the train then...)

-Vesa Karvonen