[MLton] Non-exhaustive exn fn match

Stephen Weeks MLton@mlton.org
Mon, 18 Jul 2005 16:58:40 -0700

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

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