[MLton] Non-exhaustive exn fn match

[Stephen Weeks]

> > That code also has a space leak.  The problem is explained (and fixed)
> > on mlton.org/UniversalType.  As to thread unsafety, it seems easy
> > enough to wrap the projection function in a MLton.Thread.atomically to
> > achieve thread safety.
> 
> 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.  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.

> 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.