[MLton] Non-exhaustive exn fn match

[Stephen Weeks]

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

Fair enough.

> The cost would increase significantly if the thread implementation
> supports true parallelism and you actually have multiple processors.
 
Agreed.

> I would expect that the performance of an exception based solution
> would always be good enough.

Maybe.  One reason I am sensitive to this tradeoff is that I actually
sat down many years ago and counted the bytes each solution took with
the then-current MLton.  I was concerned because MLton uses property
lists (based on a universal type) pervasively, and with whole-program
compilation, scalability is a concern -- every byte counts.  Looking
at the MLton sources, I see I chose to use the exn-based approach,
purely based on saving a word or two per property as I recall.  But it
may be the case that now with ref flattening, that the tradeoff goes
the other way.  In any case, my point is that if one is really
sensitive to space concerns and doesn't care about threading, the ref
solution could be the right choice.  Although, obviously, MLton has
survived with exn-based properties for some time, I wouldn't turn down
an easy space reduction if I saw one.

I guess I can agree with the following:

  * the exn-based solution is easier to understand and maintain
  * in a multi-threaded application, the exn-based solution is likely
    to be faster
  * in a single-threaded application, it is unclear which is faster
    and should be measured
  * in both single and multi-threaded applications, it is unclear
    which takes less space and should be measured